Retail Banking Business Information Model

Every Bank Has Six Definitions of Customer

Retail Banking Business Information Model is a structured inventory of the business data entities a retail bank runs on — party, customer, account, product, transaction, collateral, channel — organized into foundational, transactional and informational layers, in an editable Word document with a guide to business data modeling.

Ask a retail bank what a customer is and you will get an answer from the core, a different one from the CRM, a third from the card platform, and a fourth from the marketing warehouse. Each is correct inside its own system. None of them is the bank's definition, because the bank does not have one.

That is not a data quality problem, and cleaning the data will not fix it. It is a modeling problem: nobody has written down, in business language, what the bank means by a party, how a party relates to an account, and what distinguishes a customer from a signatory from a beneficial owner.

This model states those definitions. It is a business information model, not a database design — it names the entities the bank actually talks about and how they relate, which is the layer where the disagreements live and the only layer where they can be settled.

The Arguments This Is Meant to End

Three definitional disputes that surface in every banking data program.

Party, customer, or account holder? A joint account has two holders and possibly one relationship. A business account has an entity and several signatories. Without a party model those cases are handled differently by each system and reconciled by nobody.

What is a product, exactly? Product means a marketed offer to one team, a rate-and-fee configuration to another, and a general ledger code to a third. The model separates the three so a conversation about product can be about one of them.

Where does a transaction actually live? A card purchase exists as an authorization, a posting and a statement line, on different clocks. Naming them as distinct entities is what stops "transaction count" meaning three things.

Why This Matters Now

Three programs on most bank roadmaps all fail in the same place, and it is this one.

Core Migration Is a Mapping Exercise Before It Is a Cutover

Migrations are scoped from system inventories and delivered as data mappings. Without a business-language target, every mapping decision becomes a debate between two vendors' schemas.

Customer 360 Requires an Agreed Customer

Single-view programs stall on identity resolution because identity was never defined. The rules cannot be written before the entity is.

Reporting Obligations Assume Definitions the Bank Has Not Made

Regulatory returns ask for counts of things — customers, accounts, exposures — on the assumption those are unambiguous. Where they are not, the return is assembled by hand each period.

What Is Included

Two files:

Who This Is Built For

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

How to Put It to Work

• Use it as the straw man in a definitions workshop — arguing with a draft is faster than starting from a blank page.
• Map each entity to the systems that claim to master it, and see how many claim the same one.
• Assign ownership at entity level rather than at system level.
• Use it as the business-language target for a core migration mapping.

Where Banks Typically Start

What You Are Actually Buying Is Time

Producing this internally means a series of definitional workshops with people who each already have a working definition and reasons to defend it. The first draft is the expensive part.

• You edit rather than originate. The entities and definitions are drafted; your effort goes to your product set, your terminology, and your organizational structure.
• Arguing with a draft is faster. A workshop given a proposed definition converges in an hour. The same workshop given a blank page spends the hour on scope.
• It stays useful. The same model serves a migration mapping, a governance rollout, and a catalog build.

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.