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.

Document control

Approvals

Revision history

Contents

1. Business scope and context
2. BIAN alignment approach
3. Value chain and capability view
4. Service domain mapping
5. Control records and behaviour qualifiers
6. Service operations and APIs
7. Core banking interplay
8. ISO 20022 alignment
9. Information model and data ownership
10. Coexistence with legacy and migration
11. Non-functional, security and resilience design
12. Regulatory touchpoints
13. Roadmap and governance
14. Traceability matrix
15. Glossary and references

1. Business scope and context

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

1.3 Drivers and constraints

2. BIAN alignment approach

2.1 Release and sources

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

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

3. Value chain and capability view

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.

4. Service domain mapping

4.1 Mapping table

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

4.4 Ownership conflicts

5. Control records and behaviour qualifiers

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.

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

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

6.1 API style decision

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

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

7. Core banking interplay

7.1 Core coverage decision

7.2 Integration pattern with the core

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

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

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

10.1 Transitions

10.2 Coexistence design

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

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

13. Roadmap and governance

13.1 Roadmap

13.2 Open decisions and risks

13.3 Mapping governance

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

14. Traceability matrix

15. Glossary and references

15.1 Glossary

15.2 References

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.