BIAN Banking Architecture
How Do BIAN Service Domains Build the Business Object Model (BOM)?
The BIAN Business Object Model, or BOM, is the information architecture that connects every BIAN Service Domain into one consistent picture. It is built by modeling what each Service Domain needs to know, then combining those individual models into a single reference model for banking data.
What Is the BIAN Business Object Model (BOM)?
The BIAN Business Object Model is a reference model for information architecture in financial services, developed by BIAN eV. It identifies the Business Objects that any bank works with — products, agreements, accounts — and maps how they relate, independent of a specific bank's systems or internal terminology.
Existing banking data standards, such as ISO 20022, IFX, and SWIFT, mostly describe the messages exchanged between systems rather than the underlying objects those messages refer to. The BIAN BOM takes a different starting point: it models the Business Objects themselves, independent of any single message format, as explained in the BIAN 2nd Edition book, section 2.6.
How Do BIAN Service Domains Create the BOM?
Each BIAN Service Domain models its own information needs, recorded in its Control Record, which results in a separate Service Domain BOM. BIAN then consolidates all of these individual domain models into the single, overarching BIAN BOM, so the whole framework shares one consistent information architecture.
As the book puts it: "The BIAN BOM is elaborated by modeling the information needs of every BIAN Service Domain, as expressed in its Control Record, according to the 'Business Object Modeling approach'." This shared approach keeps every Service Domain BOM aligned with the same rules, so the pieces fit together instead of contradicting each other.
What Is the Difference Between a Business Object and a Business Concept?
A business concept is anything a business wants information about, such as "customer," while a business object is the concrete unit of information that actually carries that data, such as "party." In BIAN's model, "customer" is simply a role a party plays, not a separate object.
As the book states: "The building block of the Business Information Architecture is the Business Object. It is a mutually exclusive, collectively exhaustive unit of information." The same party could also be a supplier or a co-worker, depending on the role it plays in a given agreement.
What Business Objects Make Up the BOM Content Pattern?
The content pattern is one of two abstract reference models behind the BOM, and it defines six types of Business Objects: Products and Services, Agreement, Arrangement, Instruction, Transaction, and Account with Account Entries. Together they describe, at a high level, how any business sells something and records the results.
A product sale leads to an Agreement with a party, which is expressed through one or more Arrangements. An Instruction triggers the Transactions needed to fulfil those arrangements, and the outcome is registered as Account Entries on an Account. This same pattern applies whether you're looking at a current account, a loan, or a payment service.
What Does the BOM Structure Pattern Add?
The structure pattern enriches the content pattern by describing how each Business Object can be classified, described, and related to other objects. It introduces Business Object Types, Business Object Descriptors, and Business Object Relationship Types, which give every object in the BIAN BOM a consistent, detailed shape.
A Party, for example, can be typed as an individual or an organization, and described with attributes such as gender or date of birth. Relationships work the same way: the concept 'spouse' is defined as a relationship between two parties, created by a marital agreement.
What Does a Service Domain BOM Diagram Show?
A Service Domain BOM diagram is a UML class diagram showing the Business Objects a specific Service Domain manages, shown in white, next to objects from other Service Domains that it only references, shown in red. Together, these diagrams make up the full BIAN BOM.
As the book describes it: "These 'red' Business Object are the 'sticking edges' that link Service Domain views on the BIAN BOM together." In the Payment Order Service Domain, for instance, 'Party' and 'PartyRole' appear in red because they're actually managed by the Party Reference Data Directory Service Domain.
One Model, Many Service Domains
The BIAN BOM turns dozens of separate Service Domain views into a single, consistent information architecture for banking.
Ways to learn this standard
BIAN Foundation eLearning
Request a quote from a training partner
Frequently asked questions
This book explains the BOM approach, the content and structure patterns, and gives example diagrams, but it does not include a full attribute list or an exact count of Business Objects. For the complete, detailed model, BIAN points readers to the Digital Repository and the BIAN Wiki, where the model is maintained and expanded over time.
The book itself does not provide a downloadable file or a version number for the BOM; it explains the modeling approach rather than distributing the model. For the actual, current BOM content, BIAN directs users to its Digital Repository and the BIAN Wiki, where the model is published and kept up to date.
BIAN maps its own Business Objects and attributes onto the business components and elements of the ISO 20022 Business Model, producing what the framework calls the ISO 20022 Light Mapping. This mapping exists only for Service Domains tied to ISO 20022's business domains, such as Payments and Securities, and is published separately on the BIAN Wiki.
Enterprise architects, data architects, and business analysts working on banking information architecture get the most value from this book, since it explains the reasoning behind the BOM rather than just listing objects. Anyone mapping a bank's own data model onto BIAN's Service Domains will find the content and structure patterns a useful starting point.
Yes, the content pattern's objects sit at the highest abstraction level, and Service Domains can either use them directly or specialize them further. A current account agreement, for instance, is a more specific version of the general 'Agreement' object, which in turn can split into specific arrangement types like interest or fee arrangements.
