Situation · what this business actually is

Operators pay the owners.
Someone has to run the split.

When you own mineral rights, operators drill, sell the oil and gas, and owe you a share of the proceeds. For a book of any real size, that simple idea becomes a job: revenue arrives from a dozen operators, each in its own format, and every dollar has to be split across the families and trusts that hold a fractional interest in each well. Income, depletion, and fees get separated. Beneficiaries get statements. Taxes get filed. And when a bank holds the trust, its system needs the numbers in its exact accounting file, plus a yearly fiduciary review. Then it all happens again next cycle — every month or quarter, forever.

Family offices & multi-family trust books
Dozens of beneficiaries, fractional interests across a hundred wells, a custodian with a clock. The whole cycle becomes one approval — with proof a trustee can hand to anyone who asks.
Mineral & royalty management firms
You sell judgment; your margin dies in keying. The work that feeds your system of record stops being manual — and you can serve bank-custody books your competitors can't touch.
Trustees & advisors serving bank custodians
The bank's format is non-negotiable and the annual review doesn't move. Files in their exact layout, a compliance package on their clock, and a standing record built before anyone asks for it.
That's the business — honest, fiduciary, and relentless. The people who own these books are family offices, trustees, and the firms that administer for them, and almost none of them wanted to spend their week keying operator statements. Here's the part that makes it hard.
Problem · a translation gap with no room for error

No standard coming in.
No mercy going out.

Three structural facts make this work brutal — and no amount of care or effort makes them go away. Here they are in order.

First · the raw material arrives in nine private languages

Nine operators.
Nine private languages.

Every operator formats its check detail differently — different columns, different deduction logic, different ways of saying the same thing. There is no industry file standard for what lands in your mailbox. That's not an inconvenience; it's the reason this entire category of work exists.

Operator A · paper stub
WELL 34-091  GRS 4,182.07
SEV TX -192.38  DED? -88.10
NET 3,901.59  DEC .00482913
Operator B · PDF, different logic
PROP: SMITH 2H | NET of tax
OWNER INT: 0.0211 RI
AMT: 1,204.66  (deducts folded in)
Operator C · portal export
prod_mo,gross,tx1,tx2,mkt,net
2026-03,988.41,45.4,12.2,31.9,898.91
check # on a different page
Three of nine, lightly disguised. Same economic event — a well paid an owner — written three incompatible ways. Multiply by nine operators, twelve months, and 2,284 lines a year (151 royalty monthly plus 118 fee quarterly), and you have the reading half of the job.
Second · the destination accepts no approximation

The bank doesn't
read intent. It reads bytes.

Reading the paper is only half the difficulty. The other half is harder: a bank trust system doesn't accept a spreadsheet and doesn't interpret what you meant. It loads a file in its exact layout — account structures, identifiers, line order, to the byte — or it rejects the whole thing. In this work, “close” doesn't exist. One mis-read decimal pays the wrong family every cycle until someone notices, and one malformed line bounces a file the day it's due.

Third · every line ties to the penny, on a deadline that never moves
So the problem, stated plainly: no standard coming in, an unforgiving standard going out, and hundreds of lines in between that each must reconcile to the penny before a cycle deadline that does not move. Miss on the read and you pay the wrong family; miss on the format and the filing bounces the day it's due. That is the problem every option in the next section is trying to solve — and what each one costs you.
The database · why translation is possible

A structured database is what
makes translation possible.

A CDEX feed gives you revenue data. A spreadsheet holds numbers. Neither holds the relationships that make a trust distribution work: which well connects to which owner, which owner maps to which trust account, what decimal interest applies to ten digits, what fee rate and depletion rate governs each account. Without those relationships held explicitly, you cannot compute a distribution — you can only type one by hand and hope the math is right.

The database holds every relationship. Wells link to owners. Owners link to accounts. Accounts carry fee schedules and depletion rates. Division orders are enforced to ten decimal digits. When revenue arrives from an operator, the database knows exactly how to split it — across every owner, every account, every trust — without a human touching a number. That is what the translator reads. That is why the bank file is byte-perfect. The precision lives in the data, not in the person formatting the spreadsheet.

CDEX feed
Revenue data. Who paid what. No relationships, no structure, no division orders.
Your mineral platform
Accounting and analytics. Tracks the portfolio. May reconcile against the bank. Doesn't produce the bank file.
The Centripetal database
Wells → owners → accounts → fees → division orders. Every relationship explicit. The translator reads this. The bank file writes from this.
Translators · engineered artifacts, not scripts

Translators are engineered
artifacts, not scripts.

A bank trust file translator is not a CSV export. It is a deterministic program that reads structured data and writes it into the bank's exact format — field by field, code by code, total by total. The spec determines where every byte goes. The translator enforces it. Same input, same output, every time. No probability. No approximation. The kind of thing that, once it is built and validated, you do not argue with — you verify it works and you use it.

Building a translator for a single bank takes weeks of engineering: reading the spec, mapping field positions, handling transaction code sequences, implementing reconciliation checks, and validating against the bank's own sample files. We have done this work. The Fifth Third FIS translator is live, proven across 10 generation runs on real data, and producing files that match the bank's spec byte for byte. Every new bank is one new translator. The database and the engine stay proven.

The payoff · what solving it gives you back

One machine. Built once.
Proven to the penny.

Here is the third option, and the whole payoff in one sentence: the reading, the splitting, the proving, and the bank's file were built once, as machinery, against real paper — so the cycle that used to take a person days now takes minutes, leaves a record an examiner accepts, and costs a fraction of any of the above. Read the diagram left to right: chaos in, proof out. The only human moment in it is yours — the approval in the middle.

THE PAPER READERS THE SPINE YOU WRITERS DESTINATIONS Operators 1–3paper stubs Operators 4–6PDF statements Operators 7–9portal exports 9 FORMATS · NO STANDARD RDR·01–03 RDR·04–06 RDR·07–09 one translator per format taught line by line · 41 runs 2,284 lines/yr · 17/17 to the penny The data spine purpose-built for this fiduciary problem 61interlocking tables 1,372deliberate fields 44computed views 36functions splitting & proving Lineage on every figure traceable to the stub it came from Completeness gate decimals must sum to the whole — or it blocks Penny reconciliation every split sums exactly back to its check Your approval nothing posts without it WTR·BANK ROYALTY1,300+ line runs WTR·BANK FEES113 lines proven WTR·MINERAL SYSbyte-validated WTR·STATEMENTSper family WTR·ANNUAL REVIEWwhole book Trust custodiantrust system · loads it as-is Your mineral systemsame import you use today 54 familiesstatements & year-end Annual bank reviewaudit-ready, on their clock The proof layer — under everything to the right of the paper every file sealed at creation  ·  permanent per-cycle reconciliation record  ·  re-run any prior delivery on command Counts pulled from the live platform, June 2026. The dashed seal is why the file the bank receives is provably the file the platform produced. RDR·10 next operator WTR·next bank room already on the spine — one more translator each, not a new machine
Delivery 01 · your mineral system
Feed the system you already run
Operator stubs in → a validated file out, loaded through the same import you use today. The keying stops; your system of record stays yours.
Delivery 02 · your trust custodian
Speak the bank's language back
The same spine → your custodian's exact trust layout. Royalty files, fee files, the annual review — penny-tied, sealed, loaded by their system as-is.
A chat window can't do this, software-you-key-into doesn't do this, and the market charges you forever for never having built it. The hard part is finished. You're buying the finished part — and you keep your systems, your data, and your proof.
What system do you run · we wrap around it

We wrap around
whatever you already use.

CDEX is table stakes — everyone can get data in. The bank file is the hard part. Select your platform and see how the integration works.

MineralSoft (Enverus)
$140K–$250K / yr
CDEX · Yes — in and out, generic consolidated, not bank-specific
Bank trust file · Not generated
The gap: CDEX output is generic consolidated — not the named FIS/CMA format your bank loads. Building a bank-specific translator on MineralSoft costs $25–60K extra.
How we integrateWe sit alongside MineralSoft. Revenue data flows through it for accounting and analytics — that doesn't change. We add automated ingestion (no manual uploads) and bank file translation (byte-perfect, any custodian format). MineralSoft does what it's good at. We fill the two gaps it doesn't.
┌─ Centripetal: first mile ────────────────────┐
│ Automated ingestion → reading → normalization │
│ Structured database (your tenant, your data)  │
└───────────────────────┬──────────────────────┘
                        ↕ data flows both ways
┌─ MineralSoft (unchanged) ────────────────────┐
│ Enverus · Accounting · Reporting · Analytics  │
└───────────────────────┬──────────────────────┘
                        ↓ structured data
┌─ Centripetal: last mile ─────────────────────┐
│ Bank file translator → byte-perfect → sealed  │
│ Reg 9 narrative → year-end → audit trail      │
└───────────────────────┬──────────────────────┘
                        ↓ file loads clean
┌─ Custodian bank ─────────────────────────────┐
│ Fifth Third (FIS) · Frost · BOK · any bank   │
└──────────────────────────────────────────────┘
MineralWare (SS&C)
$40K–$120K / yr
CDEX · Yes (in), partial (out)
Bank trust file · Not generated
The gap: Does not emit a named bank trust custodian file. Adding FIS/CMA on top: $40–80K. We already integrate with MineralWare — outbound CDEX is live on a production client.
How we integrateWe already write back to MineralWare. Our production client uses MineralWare as their system of record — we feed cleaned data into it and pull structured data out. The bank file translator reads from the same structured database that feeds MineralWare. One data source, two outputs: your accounting system and your bank's trust system.
VISION-OG (OGTS)
$20K–$680K / yr
CDEX · Yes (in), partial (out)
Bank trust file · Not generated
The gap: Reconciles against bank data but does not produce the file the bank ingests. Software tier covers CDEX only — not paper formats. Managed tier ($425–680K) does the whole job but on OGTS's roof.
How we integrateVISION-OG stays the accounting engine. We wrap the first mile (automated ingestion including paper) and the last mile (bank file in any custodian format). Your bank clients get the complete solution.
mineral.tech® (Valor)
$100K–$300K / yr
CDEX · No CDEX support
Bank trust file · Not generated
The gap: No public CDEX support — the 9-format inbound problem stays on your team. No bank trust file generation. When Frost's trust system needs a distribution file, mineral.tech doesn't produce it.
How we integratemineral.tech stays the client-facing platform. We add the data pipeline underneath: automated ingestion, structured database, and bank file translator. Your clients see mineral.tech. The bank sees a file that loads clean.
Excel / manual
no system
CDEX · No
Bank trust file · Not generated
The gap: No persistent memory between cycles. No automated ingestion. No audit trail. 20–40 hours per cycle starting from scratch every time. At 1.5% error rate per operation, odds of a clean six months are under 1%.
How we integrateWe replace the entire manual pipeline. The database holds every relationship permanently. Every cycle builds on the last. The bank file generates in seconds. Your team reviews and approves instead of reading and typing.
Questions, answered

The questions a careful
buyer should ask.

Whose systems does the data live in?
Yours. Files deliver into your mineral system and your custodian; the platform record is yours, exportable, with full lineage. Leaving costs you nothing but the goodbye — we published that on purpose.
My operators aren't your nine. Now what?
A new operator is a new reader on the existing spine — taught against your real paper, proven to the penny before it counts, quoted on the published card before work starts. Weeks, not a project.
My bank isn't the custodian you've proven. Does this still work?
Every trust custodian in the country runs on the same federal convention — structured, delimited files in the bank's own layout. Different layout, same discipline: a new bank is a new writer, validated at full volume before a live dollar moves.
How do I know the files are right?
You don't take our word: every check reconciles line-total to check-total exactly, every generated file is sealed at creation, and every cycle leaves a permanent reconciliation record. The proof is producible on demand — for the bank, an examiner, or a beneficiary's lawyer, years later.
What about security?
We prove by record, not by badge: default-deny access on every table, single-purpose tenancy, sealed outputs, immutable cycle records — and we will walk your bank's IT through the architecture directly, on their questions, before anything goes live. Ask the quote-only platforms in the comparison above for the same meeting.
How fast is live?
The reference book went from signature to a working operations app in sixteen days, and to a full year of paper read, tied, and proven inside a quarter. Your timeline is quoted in writing at engagement — like everything else here.