C02-Tue · Learn · 12 min · BF4, BF5, BF6

The Metamodel and the v14 Service Landscape

By the end you'll be able to:

Derive a Service Domain's role from its Functional Pattern and Asset Type
Explain Control Record, Generic Artifact, Behaviour Qualifier and Information Profile, with one example each
Locate Customer Offer, Underwriting, Corporate Loan and Corporate Current Account in the v14 Service Landscape

Hook

A BIAN Service Domain always does something to something. Learn to read that sentence in its name, and you can work out what a domain does, what it stores and what it can't do, without opening the spec.

Why it matters at Meridian

The SME Flex team argues about where the "decision" lives: in the offer, the loan or the credit engine. The metamodel settles it. Each Service Domain has exactly one pattern of behaviour, so only one of them can assess. This is the vocabulary for the rest of the course, and about a third of the Foundation exam.

The core idea

1. Service Domain = Functional Pattern × Asset Type. A Functional Pattern is a behaviour that can be applied to an asset in commercial business: fulfil, process, assess, catalogue, track, design, and so on. BIAN's practitioner guide defines 19. An Asset Type is the thing it's applied to: a corporate loan, a customer offer, a party's reference data. Each Service Domain combines one primary pattern with one asset type, and that makes it unique. It fulfils its role for the entire life of each asset instance.

2. Control Record and Generic Artifact. What a Service Domain manages is its Control Record. That's the information about the asset combined with the Generic Artifact, the typical record that its functional pattern produces. The pattern decides the artifact. In v14 the Control Record name is usually asset + artifact, so you can read it straight off the spec:

Service Domain	Pattern	Control Record (v14)
Customer Offer	Process	Customer Offer Procedure
Underwriting	Assess	Underwriting Assessment
Corporate Loan	Fulfill	Corporate Loan Facility
Party Reference Data Directory	Catalog	Party Reference Data Directory Entry

3. Behaviour Qualifiers and the Information Profile. A Control Record is usually broken into parts called Behaviour Qualifiers (BQs). Each functional pattern has a typical BQ type. Process breaks into work steps, Fulfill into features, Catalog into properties, and Assess into tests. The actual BQs are specific to each domain. In v14, Corporate Loan has BQs such as Disbursement, Repayment, Interest, Charge and Modification. Customer Offer has work steps such as Facility Application, Underwriting, Collateral Allocation, Agreement and Booking. Corporate Current Account, the business version of the consumer Current Account, has a Sweep BQ, which you'll need for SME Flex. v14 also has a separate Cash Concentration domain that sweeps balances between accounts as a cash-management service. Tell them apart by the asset: the account versus the customer's whole cash position. BQs should themselves be MECE.

The Information Profile is wider than the Control Record. It describes all the business information a Service Domain governs: what it uses, what it creates and what it keeps as history.

4. The Service Landscape. The Service Landscape arranges Service Domains so you can find them. The v14 Matrix View has five Business Areas: Reference Data, Sales and Service, Operations and Execution, Risk and Compliance, and Business Support. Inside them are 36 Business Domains, and inside those 341 Service Domains. Operations and Execution adds one more level: its domains are grouped into Product Specific Fulfillment (Loans and Deposits, Trade Banking, Cards, and others) and Cross Product Operations (Payments, Collateral Administration, and others). Count those two groupings as domains and you get the 38 that the v14 Release Notes report. Those notes count 322 Service Domains, not 341. The gap is close to the 18 domains added in v14, but the notes don't say why. The lesson for exams and for real work: quote a number with its source. BIAN publishes the landscape in more than one layout, including a matrix and a value-chain view. The syllabus is explicit: the landscape is an access path, not a design blueprint. Neighbours on the map don't have to be neighbours in your architecture.

The metamodel is the set of constructs and rules behind all of this, expressed in ArchiMate. It also places BIAN in the business, application and technology layers. BIAN content lives mainly in the business layer and the logical application layer. The technology choices stay yours.

Formula diagram: Functional Pattern 'Fulfill' plus Asset Type 'Corporate Loan' gives Service Domain 'Corporate Loan'. Its Control Record 'Corporate Loan Facility' combines asset information with the Generic Artifact 'Facility', and is broken down by Behaviour Qualifiers such as Disbursement, Repayment and Interest.

Worked example

Is SME Flex's working-capital line its own Service Domain? Use the formula.

Asset: a revolving credit line for a corporate customer. Pattern: fulfil the agreed arrangement over its life.
Look for Fulfill × credit line in v14. You'll find Credit Facility, whose Control Record is the Credit Line Facility, with BQs Credit Allocation and Charge.
Underwriting the line is Assess and stays in Underwriting. Offering it is Process and stays in Customer Offer.

So the working-capital line adds one fulfilment domain and reuses the rest. The formula stopped a duplicate "WC Line Origination" domain before anyone drew it.

Now place SME Flex on the v14 map:

Service Domain	Business Domain	Business Area
Customer Offer, Underwriting	Sales	Sales and Service
Party Reference Data Directory, Customer Credit Rating	Customer Management	Sales and Service
Corporate Loan, Corporate Current Account	Loans and Deposits	Operations and Execution
Credit Facility, Cash Concentration	Trade Banking	Operations and Execution
Credit Risk Models	Models	Risk and Compliance

Two surprises are worth remembering. Underwriting sits in Sales, not in Risk and Compliance: BIAN files it by where the work happens in the customer journey. And Party Reference Data Directory sits in Customer Management, not in the Reference Data area's Party domain. If you'd guessed from the names, you'd have been wrong twice. That's the landscape-is-not-a-blueprint rule in action: the map's grouping doesn't tell you who owns a decision. The pattern does.

Your turn (annotated landscape slice). Open the v14 Matrix View and check the table above. Add the pattern and Control Record next to each domain. Then mark which pairs sit far apart on the map but next to each other in the SME Flex flow.

Three nested levels from the v14 Matrix View: 5 Business Areas contain 36 Business Domains, which contain 341 Service Domains. Example path: Sales and Service, then Sales, then Customer Offer and Underwriting.

AI in this design

Ask a general-purpose LLM for "the BIAN Service Domain for SME loan approval" and you may get Loan Approval Management. It's a plausible name, and it doesn't exist. LLMs have seen many versions of BIAN and much informal writing about it. Plausible names are exactly what next-token prediction produces. That's why Wednesday's classifier is checked against an answer key built from the v14 catalogue, never from the model's memory.

Common mistakes

Treating the landscape as an architecture. It's a way of finding domains. Your design picks and connects them.
Giving a Service Domain two patterns. One primary pattern per domain. "Process and assess" means two domains.
Confusing the Control Record with a database table. It's a logical concept, and the implementation is free.
Quoting a number without its source. The v14 Matrix View draws 341 Service Domains, and the Release Notes count 322. Say which one you mean.

Recap

Service Domain = one Functional Pattern × one Asset Type. The pattern decides the Generic Artifact.
The Control Record (asset + artifact) is broken into Behaviour Qualifiers. The Information Profile covers everything the domain governs.
The v14 landscape (5 Business Areas, 36 Business Domains, 341 Service Domains in the Matrix View) is an access path, not a blueprint.

Sources

BIAN, Service Landscape v14.0, Matrix View (BIAN HTML repository). https://bian.org/servicelandscape-14-0-0/views/view_54081.html (accessed 2026-10-03)
BIAN, BIAN 14.0 Release Notes (2026), Figure 1 and section 1.2. https://bian.org/wp-content/uploads/2026/02/BIAN-v14.0-Release-Notes-v1.0_-Final-Version.pdf (accessed 2026-10-02)
BIAN, Semantic API Practitioner Guide v8.1 (2020), section 3.2 (Figures 8, 9 and 12). https://bian.org/wp-content/uploads/2024/12/BIAN-Semantic-API-Pactitioner-Guide-V8.1-FINAL.pdf (accessed 2026-10-02)
BIAN, v14 Semantic API specifications (CorporateLoan, CustomerOffer, Underwriting, CreditFacility, CorporateCurrentAccount, CashConcentration). https://github.com/bian-official/public/tree/main/release14.0.0 (accessed 2026-10-02)
Van Haren / BIAN, BIAN Banking Architecture Foundation, Syllabus Version 3 (sections 4–6, glossary). https://www.vanharen.net/bian-foundation-syllabus/ (accessed 2026-10-02)