Mapping BIAN to Technology: From Concepts to Code

This article is part of our ongoing BIAN series, where we explore how it converts its core concepts to Code.

New to the series? You may find it helpful to begin with our introductory post: “What is BIAN?”

Introduction

Modern banks are racing to modernize legacy systems, break down monoliths, and standardize their service landscapes. Banking Industry Architecture Network (BIAN) has become a global standard that sets a standard architecture for banking services. This architecture is based on clearly defined business capabilities, information models, and standardized APIs.

Figure 1: BIAN Meta model

But if you’re a developer or solution architect, BIAN’s documentation can feel conceptual, rich in models and patterns, but light on code-level translation.

This post bridges that gap.

• What each BIAN component means
• How to map those components to real code, aggregates, tables, APIs, and events
• How to implement event-driven, domain-aligned microservices

By the end, this blog demonstrates how the journey “From Concepts to Code” takes shape in practical implementation.

Understanding the BIAN Components

BIAN decomposes the bank into Service Domains, atomic, reusable business capabilities. Each domain exposes standardized behaviors, interfaces, and data definitions.

Table 1: Conceptual DNA of a digital bank.

Mapping Concepts to Code

The Lending Service Domain serves as the primary example in this blog, as it effectively demonstrates the full lifecycle from origination to repayment.

1. Control Record → Domain Aggregate, Table, and Core API

The Control Record (CR) is the master business object a Service Domain.

Developer translation:

• DDD Aggregate Root: LoanFacility
• Primary Database Table: loan_facility
• API Namespace: /lending/facilities
• Event Stream: LoanFacilityCreated, LoanFacilityApproved, LoanFacilityClosed

Figure 2 : Database Table: loan_facility

Figure 3: Aggregate Root: LoanFacility Class

2. Behavior Qualifiers → Submodules, Subresources, Child Tables

Behavior Qualifiers (BQs) are parts of a Control Record that describe what the main entity does or has.

Developer translation:

• Each BEHAVIOR QUALIFIER → submodule or handler
• Each BEHAVIOR QUALIFIER → sub-resource API (nested under Control Record)
• Each BEHAVIOR QUALIFIER → child table with FK → Control Record

Table 2: Control Record (CR) and Behavior Qualifiers(BQ) relationship

Figure 4: BEHAVIOR QUALIFIER table is linked to its parent Control Record table

3. Functional Patterns → Lifecycle & Orchestration

Functional Patterns describe how a Service Domain behaves, such as Fulfillment, Management, or Operation.

• Define lifecycle state machine
• Add Saga orchestration for cross-domain flows
• Integrate policy engines for pricing, limits, or eligibility

Example (Fulfillment Pattern — Lending):

State transitions:

• approve() → emits LoanApproved
• activate() → emits LoanActivated
• close() → emits LoanClosed

Saga orchestration:

Origination → Credit Assessment → Collateral → Disbursement → Activation

Each step emits events and listens to previous outcomes.

4. BUSINESS OBJECT MODEL → Canonical Schemas & DTO Libraries

The Business Object Model (BOM) standardizes data entities like Party, Facility, and Payment.

Developer translation:

• Canonical JSON Schemas
• Shared DTOs / OpenAPI components
• Cross-domain reference by ID, not by embedding

Table 3: BIAN business object message

5. Generic Objects → Reusable Enums and Polymorphic Records

Cross-domain classifications and asset types.

Developer translation:

• Centralized reference-data service
• Polymorphic tables with details_json for subtype data

6. APIs → Resource Design, Versioning & Semantics

BIAN APIs are semantic aligned to Service Domains, Control Record, and BEHAVIOR QUALIFIERs.

Developer translation:

• Resource-oriented REST APIs grouped by domain
• Control Record -centric endpoints: manage the main entity
• BEHAVIOR QUALIFIER-centric endpoints: manage sub-capabilities
• Versioned base paths: /v1/lending/…
• Idempotent writers, paginated reads

Figure 5: BIAN-aligned API semantics turn interoperability from aspiration into reality.

Figure 6: Events decouple domains while preserving data consistency.

Security, Compliance, and Audit Design

BIAN-aligned systems must embed regulatory principles.

Table 4: This architecture ensures traceability, auditability, and compliance with financial standards

Developer Blueprint Example

Figure 7: Directory structure for a Lending domain

Each part aligns directly with a BIAN component:

• Domain/ → Service Domain + Control Record
• Behavior Qualifier/ → Behavior Qualifiers
• Infra/ → Persistence & events
• App/ → Functional orchestration

Quick Summary Table

Table 5: BIAN mapping summery table

Final Thoughts: Turning Standards into Software

Mapping BIAN to technology brings clarity and structure to banking modernization.

• Architects gain a unified reference model.
• Developers get explicit coding patterns aligned with business semantics.
• Enterprises achieve interoperability and compliance by design.

BIAN provides the vocabulary; technology gives it syntax.

By coding directly in the BIAN model, Service Domains as microservices, Control Records as aggregates, and Behavior Qualifiers as modules.

Reference:

*https://portal.bian.org/*

*https://bian.org/servicelandscape-13-0-0/object_22.html?object=36726*

*https://portal.bian.org/service-domain-api/BIAN-13.0.0-PaymentOrder*

*https://github.com/bian-official/public/tree/main/release13.0.0/semantic-apis*

*https://bian.org*