# Banking Solution Design: [Solution name] mapped to BIAN

> Solution design for a banking change (a new product, a core banking
> replacement, a payments hub or a digital channel) expressed in the
> vocabulary of the BIAN Service Landscape, Release 14.0 (release notes
> final 20 February 2026). It records the business scope, the BIAN
> business areas and domains touched, the service domain mapping, the
> control records and behaviour qualifiers each component owns, the
> service operations exposed as APIs, the interplay with the core banking
> platform, ISO 20022 alignment, data ownership, coexistence with legacy
> systems, regulatory touchpoints and the roadmap. Replace every
> `[bracketed]` value and every row marked *Example*. Regulatory rows are
> pointers for your compliance team: this is a documentation format, not
> legal advice.

<!--
Guidance: How to use this template
- Use one document per solution, not per bank. Enterprise-wide BIAN
  adoption belongs in a capability map or reference architecture; this
  document applies BIAN to one concrete change.
- Pin the BIAN release first (section 2). Service domain names changed in
  Release 14.0, especially in the payments area; a mapping built on an
  older release will reference obsolete service domains.
- Map applications to service domains before you design APIs. BIAN is a
  partitioning model first; the semantic APIs are a by-product of a clean
  partition.
- One service domain has one owning application for each control record
  instance. Two systems owning the same control record is the most common
  defect a BIAN review finds.
- Use BIAN names exactly as the release publishes them, and describe them
  in your own words. Do not paste BIAN definitions into this document.
- Related documents: ISO 20022 Payments Design (`industry/iso20022-payments-design`),
  Open Banking API Design (`industry/open-banking-api-design`), Payment
  ledger design (`system-design/design-payment-ledger`), Digital wallet
  design (`system-design/design-digital-wallet`), Fraud detection design
  (`system-design/design-fraud-detection`), REST API specification
  (`architecture/rest-api-specification`), Solution architecture
  (`architecture/solution-architecture`).
-->

## Document control

<!-- Guidance: Name the BIAN release and the business areas in scope here, so a reviewer sees immediately which landscape the mapping is valid against. A new BIAN release adopted for the mapping is a new major version. -->

| Field | Value |
|---|---|
| Document ID | [BSD-001] |
| Solution name | [Name] |
| Change type | [New product / Core replacement / Payments hub / Channel / Regulatory change] |
| BIAN release used for mapping | [14.0] |
| Business areas in scope | [Names from the BIAN landscape] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@solution-architect] |
| Approvers/reviewers | [@enterprise-architect], [@head-of-payments], [@ciso], [@compliance-lead], [@data-owner] |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |
| Related documents | [Capability map], [ISO 20022 payments design], [Open banking API design], [Threat model] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Business owner | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Enterprise architecture | [@name] | [Decision] | YYYY-MM-DD |
| Security | [@name] | [Decision] | YYYY-MM-DD |
| Compliance and operational risk | [@name] | [Decision] | YYYY-MM-DD |
| Architecture review board | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Service domain mapping re-based from BIAN 13.0 to 14.0 payments service domains |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved for build of transition 1 |

## Contents

<!-- Guidance: Keep aligned with the headings below. -->

1. [Business scope and context](#1-business-scope-and-context)
2. [BIAN alignment approach](#2-bian-alignment-approach)
3. [Value chain and capability view](#3-value-chain-and-capability-view)
4. [Service domain mapping](#4-service-domain-mapping)
5. [Control records and behaviour qualifiers](#5-control-records-and-behaviour-qualifiers)
6. [Service operations and APIs](#6-service-operations-and-apis)
7. [Core banking interplay](#7-core-banking-interplay)
8. [ISO 20022 alignment](#8-iso-20022-alignment)
9. [Information model and data ownership](#9-information-model-and-data-ownership)
10. [Coexistence with legacy and migration](#10-coexistence-with-legacy-and-migration)
11. [Non-functional, security and resilience design](#11-non-functional-security-and-resilience-design)
12. [Regulatory touchpoints](#12-regulatory-touchpoints)
13. [Roadmap and governance](#13-roadmap-and-governance)
14. [Traceability matrix](#14-traceability-matrix)
15. [Glossary and references](#15-glossary-and-references)

## 1. Business scope and context

<!-- Guidance: State the business outcome, the products and customer segments affected, and what is explicitly out of scope. A reviewer should be able to reject a service domain in section 4 because it is not justified by a line in this section. -->

### 1.1 Business outcome

[Describe the outcome in one paragraph: what customers and the bank can
do after the change that they cannot do today.]

*Example:* Aurora Retail Bank (a fictional mid-sized bank with 2.1
million retail customers) replaces a 20-year-old deposits and payments
platform. The first release moves current accounts and outgoing euro
payments (SEPA Credit Transfer, SEPA Instant and cross-border payments
through a correspondent) onto a componentised platform, exposes account
information and payment initiation to licensed third parties, and keeps
lending on the legacy core until a later transition.

### 1.2 Scope

| ID | In scope | Out of scope |
|---|---|---|
| SCP-001 *(Example)* | Retail current accounts, overdraft limits, account charges | Savings, term deposits (transition 2) |
| SCP-002 *(Example)* | Outgoing and incoming euro credit transfers, instant and non-instant | Card issuing and acquiring |
| SCP-003 *(Example)* | Cross-border outgoing payments via one correspondent | Treasury and money-market payments |
| SCP-004 *(Example)* | Third-party access for account information and payment initiation | Commercial open finance products |
| SCP-005 *(Example)* | Customer consent records for third-party access | Marketing consent (stays in the CRM) |

### 1.3 Drivers and constraints

| ID | Type | Statement | Source |
|---|---|---|---|
| DRV-001 *(Example)* | Business | Launch an instant-payment-first current account within 12 months | Strategy paper, YYYY |
| DRV-002 *(Example)* | Regulatory | Send instant euro payments with payee verification as the regulation requires | Regulation (EU) 2024/886 |
| DRV-003 *(Example)* | Technology | Legacy core support ends at the close of YYYY | Vendor notice |
| CON-001 *(Example)* | Constraint | General ledger stays on the current finance platform | Finance decision |
| CON-002 *(Example)* | Constraint | Data must stay in EU regions | Data residency policy |

## 2. BIAN alignment approach

<!-- Guidance: Say which BIAN release you map to and how strictly you apply it. Most banks use BIAN as a reference vocabulary and partitioning guide, not as a mandatory interface standard. Write down which of the levels below you commit to, because it decides how much the API section must follow BIAN semantic APIs. -->

### 2.1 Release and sources

| Item | Value |
|---|---|
| BIAN release | [14.0] *(Example: release notes v1.0 final, 20 February 2026)* |
| Landscape view used | [Value chain view / Matrix view / Business domain list] |
| Semantic API source | [BIAN public repository, release14.0.0 folder: OpenAPI 3 and AsyncAPI 3 files] |
| Access to models | [Public HTML and repository / Member access to the full model] |
| Changes since the previous release reviewed | [Yes, with notes in 2.3 / No] |

Release 14.0 concentrated on rationalising service domain definitions,
removing service operations that were not needed, adding links to
ISO 20022 and reworking the payments area. The metrics chart in the
release notes shows a little over 320 service domains, grouped into
business areas and business domains; confirm the current count and list
in the BIAN portal for the release you adopt rather than relying on this
figure.

### 2.2 Alignment level

| Level | Meaning in this design | Chosen |
|---|---|---|
| L1 Vocabulary | Service domain names used to describe scope and ownership | [Yes / No] |
| L2 Partitioning | Every component maps to one or more whole service domains; no service domain is split across owners | [Yes / No] |
| L3 Interface semantics | Internal APIs follow BIAN service operation and behaviour qualifier semantics, with bank-specific payloads | [Yes / No] |
| L4 Semantic API conformance | Interfaces follow the published BIAN semantic API definitions, extended only where needed | [Yes / No] |

*Example:* Aurora commits to L2 for all new components and L3 for the
payments and current account APIs. L4 is not pursued, because the
packaged core product exposes its own API set and wrapping it fully in
BIAN semantic APIs would add an adapter layer with little benefit.

### 2.3 Release change review

<!-- Guidance: When the bank's earlier mappings use an older release, list the service domains that were renamed, made obsolete or newly added and say how this design handles each one. -->

| ID | Release 14.0 change | Effect on this design | Decision |
|---|---|---|---|
| RCH-001 *(Example)* | Payment Initiation renamed Payment Order Initiation | Name change only | Use the new name |
| RCH-002 *(Example)* | Payment Execution, Payment Instruction and Payment Order marked obsolete; the release notes name Payment Settlement, Payment Order Initiation and Payment Confirmation as their successors in the next release | Old mapping used Payment Execution for the payments hub | Re-map the hub to Payment Orchestration (new in 14.0) plus the named successors |
| RCH-003 *(Example)* | Payment Rail Operations renamed Payment Rail; ACH Operations and Correspondent Bank Operations marked obsolete | Scheme gateways mapped to ACH Operations | Re-map to Payment Rail |
| RCH-004 *(Example)* | Customer Consent and Payee Management added | Consent was mapped to Customer Agreement; payee lists to Party Reference Data Directory | Use the new service domains; check which behaviour qualifiers are defined yet |
| RCH-005 *(Example)* | Account statement behaviour renamed Financial Status Tracking on account service domains | API naming in 6.2 | Use the new name |

## 3. Value chain and capability view

<!-- Guidance: Place the change in the bank's value chain so reviewers can see which business areas move and which stay. Use BIAN business area and business domain names for the structure, and the bank's own capability names where they differ. -->

```mermaid
flowchart LR
  AUTH["Party Authentication"] --> POI["Payment Order Initiation"]
  CONS["Customer Consent"] --> POI
  POI --> PORCH["Payment Orchestration"]
  PORCH --> FRE["Fraud Evaluation"]
  PORCH --> REGC["Regulatory Compliance"]
  PORCH --> CUR["Current Account"]
  PORCH --> PRAIL["Payment Rail"]
  PRAIL --> PSET["Payment Settlement"] --> PCONF["Payment Confirmation"]
  CUR --> PK["Position Keeping"] --> FA["Financial Accounting"]
  PRD["Party Reference Data Directory"] --> CA_AG["Customer Agreement"]
  PDIR["Product Directory"] --> CA_AG --> CUR
```

*Example:* the diagram shows the service domains touched by transition 1
of the Aurora solution. The arrows show the main flow of an outgoing
payment, not every dependency.

| Value chain area | Business capability (bank name) | BIAN business domain | Change in this solution |
|---|---|---|---|
| *Example:* Operations and execution | Account servicing | [Business domain name from the landscape] | Replaced |
| *Example:* Operations and execution | Payments processing | [Business domain name] | Replaced |
| *Example:* Sales and service | Third-party access | [Business domain name] | New |
| *Example:* Risk and compliance | Financial crime screening | [Business domain name] | Integrated, not replaced |
| *Example:* Business support | General ledger | [Business domain name] | Unchanged, new feed |

## 4. Service domain mapping

<!-- Guidance: This is the core of the document. List every service domain the solution touches, the application or component that owns it after the change, the owner before the change, and the mapping quality. "Partial" means the application covers only some behaviour qualifiers; say which ones. Flag any service domain owned by two systems. -->

### 4.1 Mapping table

| ID | Service domain (BIAN 14.0) | Owning component after change | Owner before change | Coverage | Notes |
|---|---|---|---|---|---|
| SDM-001 *(Example)* | Current Account | Core banking product (deposits module) | Legacy core | Full | Includes charges, interest, amount blocks |
| SDM-002 *(Example)* | Position Keeping | Core banking product | Legacy core | Full | Intraday and end-of-day positions |
| SDM-003 *(Example)* | Customer Agreement | Core banking product | Legacy core | Partial | Master agreement only; product terms in SDM-001 |
| SDM-004 *(Example)* | Product Directory | Product configurator | Spreadsheet plus legacy parameters | Full | New component |
| SDM-005 *(Example)* | Party Reference Data Directory | Customer master (MDM) | CRM | Full | Golden record of the party |
| SDM-006 *(Example)* | Party Authentication | Identity platform | Channel servers | Full | Strong customer authentication |
| SDM-007 *(Example)* | Customer Consent | Consent service | None | Full | Third-party access consents; new in 14.0 |
| SDM-008 *(Example)* | Payment Order Initiation | Payments hub | Channel servers | Full | Captures and validates payment orders |
| SDM-009 *(Example)* | Payment Orchestration | Payments hub | Legacy core | Full | Routing, checks, sequencing |
| SDM-010 *(Example)* | Payment Rail | Scheme gateways (SEPA, Swift) | Legacy gateway | Full | One rail adapter per scheme |
| SDM-011 *(Example)* | Payment Settlement | Payments hub | Legacy core | Partial | Settlement for SEPA via clearing; correspondent settlement by nostro |
| SDM-012 *(Example)* | Payment Confirmation | Payments hub | None | Full | Status and confirmation to customer |
| SDM-013 *(Example)* | Payee Management | Payments hub | Channel servers | Full | Saved payees and trusted beneficiaries |
| SDM-014 *(Example)* | Fraud Evaluation | Fraud platform | Fraud platform | Full | Real-time score before release |
| SDM-015 *(Example)* | Regulatory Compliance | Sanctions screening engine | Sanctions screening engine | Partial | Sanctions screening only |
| SDM-016 *(Example)* | Financial Accounting | General ledger | General ledger | Full | Unchanged; new posting feed |
| SDM-017 *(Example)* | Correspondent Bank Directory | Payments hub reference data | Legacy tables | Full | Routing to the correspondent |

### 4.2 Mapping rules

1. Map whole service domains to components. When a component covers
   only part of a service domain, record the covered behaviour qualifiers
   in section 5 and name the owner of the remainder.
2. Give every control record type exactly one system of record. Other
   components may hold copies but must say so in section 9.
3. Prefer a gap row over a forced fit. If no service domain describes a
   bank-specific function, record it in 4.3 and describe it in the bank's
   own words.
4. Record channel and orchestration components honestly. Channels usually
   map to session and dialogue service domains, not to the product service
   domains they call.

### 4.3 Gaps and bank-specific extensions

| ID | Function | Why no service domain fits | Decision |
|---|---|---|---|
| GAP-001 *(Example)* | Verification of payee responder for incoming requests | Spread across Payee Management and Party Reference Data Directory | Place in Payment Order Initiation component; record as extension |
| GAP-002 *(Example)* | Real-time liquidity dashboard for instant payments | Partly covered by treasury service domains outside scope | Bank-specific component; review at next release |

### 4.4 Ownership conflicts

| ID | Service domain | Competing components | Resolution | Owner |
|---|---|---|---|---|
| OWN-001 *(Example)* | Payee Management | Mobile app back end and payments hub both store payees | Hub becomes system of record; app reads through API | [@payments-architect] |
| OWN-002 *(Example)* | Customer Agreement | CRM stores signed terms; core stores agreement | Core is system of record; CRM keeps a reference | [@data-owner] |

## 5. Control records and behaviour qualifiers

<!-- Guidance: For each owned service domain, name the control record (the thing the service domain manages through its life cycle), the functional pattern, and the behaviour qualifiers implemented. Use the names from the release you pinned; BIAN spells them "Behavior Qualifier". Describe the bank's meaning in your own words. -->

BIAN describes each service domain by the control record it manages, the
functional pattern that characterises its behaviour (for example Fulfill,
Agree Term or Advise) and the behaviour qualifiers that break the control
record into its main parts. Use this section to show that each owning
component really implements the behaviour the mapping claims.

| ID | Service domain | Control record (bank meaning) | Functional pattern | Behaviour qualifiers implemented | Not implemented |
|---|---|---|---|---|---|
| CRB-001 *(Example)* | Current Account | One customer current account arrangement and its terms | [Pattern from the release] | Charge, Interest, Sweep, Debit and Credit, Payment, Booking, Amount Block, Deposit, Issued Device, Financial Status Tracking | None |
| CRB-002 *(Example)* | Payment Order Initiation | One payment order as instructed by the customer | [Pattern] | [Qualifiers as published for the release] | Bulk orders (transition 2) |
| CRB-003 *(Example)* | Customer Consent | One consent given by a customer to a third party | [Pattern] | [Check whether the release defines qualifiers yet] | Not applicable |
| CRB-004 *(Example)* | Payment Rail | One transaction on a given clearing scheme | [Pattern] | [Qualifiers] | Cheque clearing |
| CRB-005 *(Example)* | Fraud Evaluation | One evaluation of a transaction or event | [Pattern] | [Qualifiers] | Model training (Fraud Model service domain, out of scope) |

Check each new Release 14.0 service domain: the release notes say that
for the new payments service domains (Payee Management, Customer
Consent, Payment Orchestration, Payment Confirmation, Payment
Settlement) the behaviour qualifiers are still to be defined in the next
release. Where that is the case, define the
bank's own sub-structure and mark it as provisional.

### 5.1 Life cycle of the main control records

```mermaid
stateDiagram-v2
  [*] --> Captured: Payment Order Initiation
  Captured --> Validated: format, limits, payee verification
  Validated --> Screened: sanctions and fraud
  Screened --> Rejected: hit confirmed or high risk
  Screened --> Routed: Payment Orchestration
  Routed --> Submitted: Payment Rail
  Submitted --> Settled: Payment Settlement
  Submitted --> Returned: scheme return or reject
  Settled --> Confirmed: Payment Confirmation
  Rejected --> [*]
  Returned --> [*]
  Confirmed --> [*]
```

*Example:* the life cycle of an outgoing payment as it passes from one
service domain's control record to the next. Each transition is owned by
one service domain; the state names are the bank's.

## 6. Service operations and APIs

<!-- Guidance: Show how the service domain boundaries become APIs. BIAN semantic APIs use paths of the form /{ServiceDomain}/{controlRecordId}/{BehaviourQualifier}/{qualifierId}/{Action}, with action terms such as Initiate, Update, Control, Exchange, Execute and Retrieve. Decide whether you keep that style or translate it into resource-oriented REST, and record the decision. -->

### 6.1 API style decision

| Option | Description | Pros | Cons |
|---|---|---|---|
| A. BIAN semantic API style | Paths and action terms as published, payloads extended | Direct traceability to BIAN; reuse of published OpenAPI files | Verb-style paths differ from the bank's REST guidelines; large generic payloads; no published semantic API files yet for the service domains added in 14.0 |
| B. Resource-oriented REST with BIAN mapping | Bank REST conventions; each operation tagged with its BIAN service domain and action term | Fits existing API guidelines and gateway tooling | Mapping has to be maintained by hand |
| C. Vendor APIs unchanged | Expose the packaged product APIs | Lowest effort | No common vocabulary; vendor lock-in visible to consumers |

Decision: [*Example:* Option B for external and channel APIs; option A
patterns for event names. Reason: the bank's REST API guidelines and the
open banking standard drive the public shape, while BIAN tags give the
traceability enterprise architecture needs.]

### 6.2 Operation catalogue

| ID | Service domain | Behaviour qualifier | Action term | Bank API operation | Consumer |
|---|---|---|---|---|---|
| OPS-001 *(Example)* | Current Account | Financial Status Tracking | Retrieve | GET /accounts/{id}/balances | Mobile app, third parties |
| OPS-002 *(Example)* | Current Account | Amount Block | Initiate | POST /accounts/{id}/holds | Payments hub |
| OPS-003 *(Example)* | Payment Order Initiation | [Qualifier] | Initiate | POST /payment-orders | Mobile app, third parties |
| OPS-004 *(Example)* | Payment Order Initiation | [Qualifier] | Retrieve | GET /payment-orders/{id} | Mobile app, third parties |
| OPS-005 *(Example)* | Customer Consent | Not applicable | Initiate | POST /consents | Open banking gateway |
| OPS-006 *(Example)* | Customer Consent | Not applicable | Control | POST /consents/{id}/revoke | Customer dashboard |
| OPS-007 *(Example)* | Fraud Evaluation | [Qualifier] | Execute | POST /fraud-evaluations | Payments hub |
| OPS-008 *(Example)* | Payment Confirmation | Not defined in 14.0 | Not applicable (event) | Event payment.confirmed | Channels, notifications |

Check the release's semantic API file before fixing an L4 mapping:
some model behaviour qualifiers (for example Financial Status Tracking
on Current Account in 14.0.0) have no published endpoint yet, so OPS-001
stays at the service domain and qualifier level.

Specify each API with the REST API specification template
(`architecture/rest-api-specification`) and each event with the event
API specification (`architecture/event-api-specification`); this table
only fixes the boundary and the BIAN tag.

### 6.3 Events

| ID | Event | Producing service domain | Consumers | Delivery |
|---|---|---|---|---|
| EVT-001 *(Example)* | payment.order.captured | Payment Order Initiation | Fraud, notifications | At least once, ordered by order ID |
| EVT-002 *(Example)* | payment.settled | Payment Settlement | Current Account, Financial Accounting | At least once, idempotent consumers |
| EVT-003 *(Example)* | consent.revoked | Customer Consent | Open banking gateway, audit | At least once, within 5 seconds |
| EVT-004 *(Example)* | account.posting.created | Current Account | Financial Accounting, statements | Ordered per account |

## 7. Core banking interplay

<!-- Guidance: A packaged core usually covers many service domains at once. State which ones you use from the core, which you deliberately take outside it, and why. The test is whether you could replace one outside component without touching the core. -->

### 7.1 Core coverage decision

| Service domain | Use core product | Use separate component | Reason |
|---|---|---|---|
| Current Account | *Example:* Yes | | Product engine and interest are core strengths |
| Position Keeping | *Example:* Yes | | Tight coupling with postings |
| Product Directory | | *Example:* Yes | Product team needs configuration without core releases |
| Payment Orchestration | | *Example:* Yes | Scheme changes are frequent; hub vendor updates yearly market practices |
| Customer Consent | | *Example:* Yes | Shared by open banking and channels; core has no consent model |
| Financial Accounting | | *Example:* Yes | Existing general ledger kept (CON-001) |

### 7.2 Integration pattern with the core

| ID | Interaction | Pattern | Consistency | Failure handling |
|---|---|---|---|---|
| INT-001 *(Example)* | Hub reserves funds on the account | Synchronous API (Amount Block Initiate) | Strong for the reservation | Timeout leads to status query before retry |
| INT-002 *(Example)* | Hub posts the settled payment | Event with idempotency key | Eventual, under 2 seconds | Dead letter queue, operations alert |
| INT-003 *(Example)* | Core publishes postings to the ledger | Batch every 15 minutes plus end-of-day file | Eventual | Reconciliation break report |
| INT-004 *(Example)* | Product Directory publishes product versions to the core | API with versioned product definitions | Strong at activation | Activation blocked until acknowledged |

For the posting and reconciliation detail, reuse the payment ledger design
(`system-design/design-payment-ledger`); for stored-value accounts, see
the digital wallet design (`system-design/design-digital-wallet`).

## 8. ISO 20022 alignment

<!-- Guidance: BIAN 14.0 adds links between its business object model and ISO 20022. Record where this solution exchanges ISO 20022 messages, which internal objects they map to, and who owns the mapping. Put message-level detail in the ISO 20022 payments design and keep only the alignment here. -->

| ID | Service domain | ISO 20022 messages exchanged | Internal object | Mapping owner |
|---|---|---|---|---|
| ISO-001 *(Example)* | Payment Order Initiation | pain.001 from corporate channels; pain.002 status | Payment order | Payments hub team |
| ISO-002 *(Example)* | Payment Rail | pacs.008, pacs.002, pacs.004, camt.056, camt.029 | Scheme transaction | Gateway team |
| ISO-003 *(Example)* | Payment Rail | pacs.009 for cover and bank-to-bank transfers | Scheme transaction | Gateway team |
| ISO-004 *(Example)* | Current Account | camt.052, camt.053, camt.054 for corporate reporting | Account statement and notification | Core team |

Design rules:

1. Use the ISO 20022 business components (party, agent, account,
   remittance, purpose) as the vocabulary of the internal payment object,
   so that no data is lost when translating to and from the scheme.
2. Keep the full structured party and address data from the message in
   the control record, even when a legacy consumer can only show part of
   it.
3. Carry the end-to-end identifier and the unique end-to-end transaction
   reference (UETR) from initiation to confirmation and into the ledger.

Details: ISO 20022 Payments Design (`industry/iso20022-payments-design`).

## 9. Information model and data ownership

<!-- Guidance: Name the system of record for each major business object, its classification, and the copies held elsewhere. BIAN's business object model gives the names; the bank decides ownership. Pay most attention to party data, because it is usually copied the most. -->

| ID | Business object | System of record | Copies held by | Classification | Retention |
|---|---|---|---|---|---|
| DAT-001 *(Example)* | Party (customer) | Customer master | Core, CRM, payments hub (cache) | Personal data, confidential | Relationship plus statutory period |
| DAT-002 *(Example)* | Current account arrangement | Core banking | Data platform | Confidential | Relationship plus statutory period |
| DAT-003 *(Example)* | Payment order and status history | Payments hub | Data platform, fraud platform | Personal data, confidential | Statutory record-keeping period |
| DAT-004 *(Example)* | Consent | Consent service | Open banking gateway (cache) | Personal data | Consent life plus audit period |
| DAT-005 *(Example)* | Product definition | Product Directory | Core (activated versions) | Internal | All versions kept |
| DAT-006 *(Example)* | General ledger posting | General ledger | Data platform | Confidential | Accounting retention period |

Rules for copies:

- A copy states its freshness target and the event or feed that keeps it
  current.
- A copy never becomes a second source of updates. Changes go to the
  system of record through its API.
- Personal data copies are listed in the record of processing activities
  and covered by the data protection impact assessment where one is
  needed.

## 10. Coexistence with legacy and migration

<!-- Guidance: Most BIAN-aligned programmes run old and new platforms side by side for months. Describe the transitions, which service domains move in each, how routing works while both exist, and how data migrates. -->

### 10.1 Transitions

| Transition | Service domains moved | Routing rule during coexistence | Exit criteria |
|---|---|---|---|
| T1 *(Example)* | Payment Order Initiation, Payment Orchestration, Payment Rail, Payment Confirmation, Payee Management, Customer Consent | New hub handles all outgoing payments; legacy core still holds accounts and posts through an adapter | Two month-end closes without unreconciled breaks |
| T2 *(Example)* | Current Account, Position Keeping, Customer Agreement | Accounts migrate in waves by branch; hub routes by an account location table | All accounts migrated; legacy in read-only mode |
| T3 *(Example)* | Lending service domains | Out of scope of this document | Separate design |

### 10.2 Coexistence design

```mermaid
flowchart LR
  CH["Channels and third parties"] --> GW["API gateway"]
  GW --> HUB["Payments hub"]
  HUB --> LOC{"Account location"}
  LOC -->|migrated| NEW["New core"]
  LOC -->|not migrated| ADP["Legacy adapter"]
  ADP --> OLD["Legacy core"]
  NEW --> GL["General ledger"]
  OLD --> GL
```

| ID | Coexistence risk | Mitigation |
|---|---|---|
| COX-001 *(Example)* | Same customer has accounts on both cores; internal transfer spans both | Hub treats it as two legs with a suspense account; reconciliation daily |
| COX-002 *(Example)* | Legacy cut-off times differ from 24/7 instant processing | Adapter queues postings out of hours; balance check uses reservations in the hub |
| COX-003 *(Example)* | Statement continuity across migration | Statement service merges history from both cores for the migration year |

Plan the migration waves and reconciliation with the data migration
strategy (`architecture/data-migration-strategy`) and the cutover plan
(`project/cutover-plan`).

## 11. Non-functional, security and resilience design

<!-- Guidance: Give the targets per service domain group, because a payments service domain and a product directory need very different service levels. Link each important business service to its tolerance for disruption, which operational resilience rules in many jurisdictions require. -->

| ID | Scope | Requirement | Target | Evidence |
|---|---|---|---|---|
| NFR-001 *(Example)* | Payment Order Initiation to Payment Rail, instant payments | End-to-end processing inside the bank | 95th percentile under 1.5 seconds, leaving scheme time within the 10-second limit | Load test report |
| NFR-002 *(Example)* | Payments hub | Availability | 99.95 percent monthly, 24/7 | SLO dashboard |
| NFR-003 *(Example)* | Current Account balance retrieval | Latency | 95th percentile under 300 ms | APM |
| NFR-004 *(Example)* | All payment service domains | Recovery point | No acknowledged payment lost (RPO zero) | DR test |
| NFR-005 *(Example)* | Payments hub | Recovery time | Under 30 minutes for region failure | DR test |
| NFR-006 *(Example)* | Product Directory | Availability | 99.5 percent, business hours support | SLO dashboard |

Security design points:

- Authenticate customers once in Party Authentication and pass a signed
  token with the authentication strength; product service domains check
  the strength rather than re-authenticating.
- Enforce entitlements (who may act on which account) in one place and
  log every decision.
- Score every outgoing payment in Fraud Evaluation before release; see
  the fraud detection design (`system-design/design-fraud-detection`).
- Keep card data out of these components; if cards come into scope later,
  scope them with PCI DSS scoping (`compliance/pci-dss-scoping-segmentation`).
- Model threats per trust boundary with the threat model template
  (`security/threat-model`).

## 12. Regulatory touchpoints

<!-- Guidance: List the rules that shape the design, the service domain that carries each obligation and the evidence the design produces. Article numbers and dates must be checked in the consolidated text by compliance. This is a documentation format, not legal advice. -->

| ID | Rule (check the consolidated text) | Obligation in brief | Service domain | Design evidence |
|---|---|---|---|---|
| REG-001 *(Example)* | Regulation (EU) 2024/886 on instant credit transfers, amending Regulation (EU) No 260/2012 | Offer instant euro payments at no higher charge than standard transfers, verify the payee before authorisation, screen own customers against EU sanctions lists at least daily; euro-area deadlines 9 January 2025 (receive) and 9 October 2025 (send, payee verification) | Payment Order Initiation, Payment Orchestration, Regulatory Compliance | Sections 4, 8; ISO 20022 design |
| REG-002 *(Example)* | Directive (EU) 2015/2366 (PSD2) and Delegated Regulation (EU) 2018/389 (strong customer authentication and secure communication) | Strong customer authentication, dedicated interface for third parties | Party Authentication, Customer Consent | Open banking API design |
| REG-003 *(Example)* | Regulation (EU) 2022/2554 (DORA), applicable from 17 January 2025 | ICT risk management, incident reporting, resilience testing, register of ICT third-party arrangements | All, especially packaged core and cloud providers | DORA register (`compliance/dora-ict-third-party-register`) |
| REG-004 *(Example)* | Regulation (EU) 2016/679 (GDPR) | Lawful processing, minimisation, data subject rights | Party Reference Data Directory, Customer Consent | Section 9, DPIA |
| REG-005 *(Example)* | Anti-money-laundering rules applicable to the bank | Customer due diligence, transaction monitoring, record keeping | Regulatory Compliance and related service domains | Financial crime design |
| REG-006 *(Example)* | Payment Services Regulation and PSD3 (agreed texts approved in committee on 5 May 2026; not in the Official Journal as of October 2026) | Future changes to third-party access, fraud liability and payee verification | Customer Consent, Payment Order Initiation | Watch item in section 13 |

## 13. Roadmap and governance

<!-- Guidance: Show the transitions on a timeline, the decisions still open, and how the BIAN mapping is kept current. Without an owner the mapping decays within one release cycle. -->

### 13.1 Roadmap

| Milestone | Date | Content | Dependency |
|---|---|---|---|
| M1 *(Example)* | YYYY-MM-DD | Payments hub live for SEPA Credit Transfer | Scheme certification |
| M2 *(Example)* | YYYY-MM-DD | Instant payments and payee verification live | M1, scheme connection |
| M3 *(Example)* | YYYY-MM-DD | Cross-border payments live with structured addresses | Correspondent testing |
| M4 *(Example)* | YYYY-MM-DD | Account migration wave 1 | T2 readiness |
| M5 *(Example)* | YYYY-MM-DD | Legacy core read-only | All waves complete |

### 13.2 Open decisions and risks

| ID | Type | Description | Owner | Due |
|---|---|---|---|---|
| DEC-001 *(Example)* | Decision | Whether to adopt BIAN event names for all internal events | [@enterprise-architect] | YYYY-MM-DD |
| RSK-001 *(Example)* | Risk | Packaged core cannot expose amount blocks with the latency needed for instant payments | [@core-lead] | YYYY-MM-DD |
| RSK-002 *(Example)* | Risk | A later BIAN release replaces service domains used here | [@enterprise-architect] | Each release |
| RSK-003 *(Example)* | Risk | Final PSR text changes consent or liability rules | [@compliance-lead] | On publication |

### 13.3 Mapping governance

| Activity | Frequency | Owner | Output |
|---|---|---|---|
| Review mapping against each new BIAN release | Each release | Enterprise architecture | Updated section 2.3 and 4 |
| Check new components for ownership conflicts | Each design review | Architecture review board | Entries in 4.4 |
| Update API tags when operations change | Each API release | API owners | Section 6.2 |
| Reconcile mapping with the application portfolio | Quarterly | Enterprise architecture | Portfolio tags |

Record significant choices as ADRs (`architecture/adr-full`).

## 14. Traceability matrix

<!-- Guidance: Link drivers to service domains, components, APIs and tests. Every driver needs at least one service domain, and every service domain owned by the solution needs at least one driver. -->

| Driver | Scope | Service domain mapping | Operations and events | Requirement | Test or evidence |
|---|---|---|---|---|---|
| DRV-001 *(Example)* | SCP-001, SCP-002 | SDM-001, SDM-008, SDM-009 | OPS-001, OPS-003, EVT-001 | NFR-001 | Performance test PT-01 |
| DRV-002 *(Example)* | SCP-002 | SDM-008, SDM-013, SDM-015 | OPS-003, OPS-007 | REG-001 | Scheme certification, payee verification test VOP-01 |
| DRV-003 *(Example)* | SCP-001 | SDM-001, SDM-002, SDM-003 | INT-001 to INT-004 | NFR-004, NFR-005 | Migration rehearsal MR-01 |
| *Example:* Third-party access | SCP-004, SCP-005 | SDM-006, SDM-007 | OPS-005, OPS-006, EVT-003 | REG-002 | Conformance test results |

## 15. Glossary and references

<!-- Guidance: Define BIAN terms in your own words for readers outside architecture, and list the exact release and documents used. -->

### 15.1 Glossary

| Term | Meaning in this document |
|---|---|
| Service Landscape | BIAN's published map of service domains grouped into business areas and business domains |
| Business area, business domain | The two grouping levels above service domains in the landscape |
| Service domain | The smallest BIAN partition: one discrete business capability with clear responsibility |
| Control record | The business entity a service domain manages through its whole life cycle |
| Functional pattern | The type of behaviour a service domain performs on its control record |
| Behaviour qualifier | A main part or aspect of a control record that operations can address separately; BIAN spells it "Behavior Qualifier" |
| Service operation | A request one service domain offers to others, named with an action term |
| Action term | The verb of a service operation, such as Initiate, Update, Control, Exchange, Execute or Retrieve |
| Semantic API | BIAN's published API definition for a service domain, derived from its operations |
| Business object model | BIAN's model of business objects and attributes used by control records |
| UETR | Unique end-to-end transaction reference carried in payment messages |

### 15.2 References

| Reference | Version or date | Use |
|---|---|---|
| BIAN Service Landscape and release notes, bian.org | Release 14.0, release notes v1.0 final 20 February 2026 | Service domain names, release changes |
| BIAN public repository (semantic APIs), github.com/bian-official/public | release14.0.0 folder, OpenAPI 3 and AsyncAPI 3 | API path pattern and action terms |
| ISO 20022, iso20022.org | Message versions per scheme | Section 8 |
| Regulation (EU) 2024/886, EUR-Lex | OJ 19 March 2024 | REG-001 |
| Directive (EU) 2015/2366 and Delegated Regulation (EU) 2018/389, EUR-Lex | Consolidated texts | REG-002 |
| Regulation (EU) 2022/2554 (DORA), EUR-Lex | Consolidated text | REG-003 |
| [Bank capability map] | [Version] | Section 3 |

## Standard and licence note

Structure aligned with the BIAN Service Landscape, Release 14.0, and its
concepts of business areas, business domains, service domains, control
records, functional patterns, behaviour qualifiers and service
operations, as published by BIAN e.V. BIAN documentation is copyright of
BIAN e.V. and the semantic API files in the BIAN public repository are
published under the Apache License 2.0; this template uses only names of
BIAN concepts and service domains, and all descriptions are original
text written for this collection. No BIAN definitions, tables or
diagrams are reproduced. EU legal acts are cited by number with original
summaries; check the consolidated texts on EUR-Lex. Check the current
BIAN release and service domain list at bian.org before use. This is a
documentation format, not legal advice. BIAN is a trademark of its
owner; this template is not affiliated with or endorsed by BIAN.
Template licence: MIT.