A payments program generates revenue from interchange, fees, float, and settlement speed premiums. Whether that revenue is captured — and whether the program can measure what it's capturing — depends on the data model underlying the payment flow. Programs with poorly designed data models leave revenue uncaptured and can't identify where the gap is.
This is the profitability gap: the difference between the revenue a payment program could theoretically generate and the revenue it actually captures, driven primarily by data model design decisions made at implementation that nobody revisits post-launch.
What "poor data model design" actually means
In payments, the data model determines how transaction data is structured, stored, and attributed. A clean, granular data model assigns unique identifiers to every transaction, tracks revenue attribution at the transaction level, and creates a complete audit trail from payment initiation through settlement. A poor data model aggregates transactions into batches, stores revenue data at the payment-type level rather than the transaction level, and makes it impossible to determine which specific transactions generated what revenue.
The practical consequence: programs with poor data models can't measure interchange yield by transaction type, can't identify which BIN structures are generating the highest interchange rates, can't verify that Level 2/3 data is being transmitted correctly to capture enhanced interchange, and can't reconcile FBO balance changes to individual transactions. They know the total revenue but can't optimize it because they can't see it at the level where the optimization decisions are made.
The interchange optimization problem
Interchange rates vary by transaction type, card type, and data quality. A commercial card transaction at interchange category Level 1 (basic data) earns a different rate than the same transaction at Level 2 (enhanced data including tax amount and customer reference) or Level 3 (full line-item detail). The difference between L1 and L3 on a commercial transaction can be 30–60 basis points. On a program processing $50M monthly in commercial card transactions, 40bps is $200,000 per month in foregone revenue.
Programs can't capture Level 2/3 interchange without transmitting the right data. Whether the right data is being transmitted — and whether the interchange rate uplift is being captured — is only visible if the data model tracks interchange rate, data level transmitted, and transaction-level revenue for every card payment. Programs without that granularity assume they're capturing enhanced interchange but can't verify it.
The reconciliation cascade
A well-designed data model enables automated reconciliation: every dollar that enters the FBO account is matched to a transaction, which is matched to the corresponding revenue entry, which is matched to the customer ledger. The match rate is the measure of data model quality. Programs achieving 95%+ automated match rates have a data model designed for reconciliation. Programs at 60–70% are generating significant manual reconciliation overhead — which is both a cost problem and a signal that the data model isn't capturing full transaction detail.
The manual reconciliation exceptions are exactly the transactions where revenue attribution is unclear. They're also disproportionately the transactions where revenue was either miscaptured or missed entirely. The reconciliation failure rate correlates strongly with the revenue measurement gap.
Designing for revenue visibility from launch
The data model needs to be specified before the BaaS implementation begins — not retrofitted after launch. The key elements: transaction-level unique identifiers that persist through settlement, interchange rate and data level attributed per transaction, revenue line items separated by type (interchange, fee, float yield, speed premium), and automated FBO balance reconciliation to transaction level.
BaaS providers vary significantly in the granularity of data they provide. Some offer transaction-level settlement files with full interchange detail. Others batch-settle with limited transaction-level attribution. The data requirements need to be in the vendor evaluation criteria — not discovered after signing.