Payments Business Information Model

One Payment, Three Identifiers, No Common Key

Payments Business Information Model is a structured inventory of the business data entities a payments business runs on — merchant, terminal, transaction, authorization, clearing record, settlement, funding, dispute — organized into foundational, transactional and informational layers, in an editable Word document with a guide to business data modeling.

A single card payment exists as an authorization, then a clearing record, then a line in a settlement file, then possibly a dispute. Each stage carries its own identifier, arrives on its own clock, and is produced by a different party. There is no natural key that runs the whole way through, which is why reconciliation is a permanent function rather than an occasional task.

Firms tend to encode the linkage in whatever their processor supplies, and then discover the limits of that model when they add a rail, change a processor, or are asked what a transaction actually cost them once interchange, scheme fees and chargeback provision are applied.

This model names those stages as distinct entities and states how they relate. It is a business information model rather than a database design — it describes what the business means, which is what has to be true before any reconciliation logic can be trusted.

The Distinctions This Is Meant to Make

Three definitional problems that make payments data uniquely awkward.

What is a transaction? An authorization, a capture, a clearing record and a settlement line describe the same payment at four moments. Modeling them as one entity with a status is the shortcut that makes reconciliation impossible to audit.

Merchant, outlet, or MID? A merchant is a legal entity; an outlet is a location; a merchant identifier is what the scheme sees. A chain has one of the first, many of the second, and an arbitrary number of the third.

Which cost applies where? Interchange, scheme fees, processor fees and provisions attach at different levels. Net revenue per transaction is only computable once each is attached to the entity it actually belongs to.

Why This Matters Now

Every strategic move in payments right now depends on a data model most firms borrowed from a vendor.

Adding a Rail Exposes a Card-Shaped Model

Account-to-account and instant rails do not have an authorization stage in the card sense. A model built around card assumptions has to be extended rather than reused.

Processor Change Means Owning Your Own Model

Where the processor's extract defines the firm's entities, changing processor is a rebuild. Where the firm has its own model, it is a mapping.

Tokenization Separated the Card From the Credential

A token, a card, an account and a customer are now four things. Firms still modeling a card number as the identity have a growing problem.

What Is Included

Two files:

Who This Is Built For

This model pairs with the Payments Capability Model, which states what the business does; the information model states what it does it to. Neither substitutes for the other.

How to Put It to Work

• Model authorization, clearing and settlement as separate entities and define how they link.
• Separate merchant, outlet and merchant identifier before attempting merchant-level analytics.
• Attach each cost component to the entity it genuinely applies to.
• Use it as the firm-owned target when mapping a processor extract.

Where Payments Firms Typically Start

What You Are Actually Buying Is Time

Building this internally means definitional sessions with people who spend their days inside a processor's data dictionary and will reach for its vocabulary by default. Breaking that habit is most of the work.

• The first draft is the expensive part. Reviewing a proposed set of entities is a different task from inventing one, and a much shorter one.
• Vendor assumptions become visible. A firm-owned draft immediately shows which of your current definitions came from a processor rather than from your business.
• It outlives the project that prompted it. The same model serves a rail addition, a processor change, and a revenue analysis.

Those first two columns describe what comparable efforts tend to involve, not a quoted benchmark — your figures depend on scope and who does the work.

Built From Real Engagements

We are software entrepreneurs and business consultants who have delivered business architecture and transformation work across financial services firms. This model is the distilled, reusable output of that work rather than a theoretical exercise — which is also why it carries the limits described below.

An Honest Note on Fit

This is a generic model designed as a starting point. Customization is expected, not a sign that something went wrong.

Specifically:

Terms You Should Know Before Purchasing

Read the description above in full before you buy. Delivery is immediate and the files are yours to keep, which is also why we cannot take returns, issue refunds, or swap a purchase for a different product once it has been downloaded. What you receive is what is listed — no warranty beyond that, and no bundled customization, implementation help, or support. A Enterprise License covers everyone inside one organization; if you intend to reuse the material across several clients, the Consultancy License is the one you need. The full digital product terms govern the sale.