Domain-Driven Design in Banking

Domain-Driven Design (DDD) is a powerful approach to software development that aligns technical implementation with business domains. However, applying DDD in banking—especially in highly regulated, legacy-heavy environments—is fraught with challenges.

Banks operate under strict constraints: compliance, security, risk management, and complex transactional systems. These constraints make DDD adoption difficult but not impossible. Worse yet, some banks mistakenly believe that adopting standards like BIAN (Banking Industry Architecture Network) solves their domain modeling problems—especially in Latin America, where BIAN’s European-centric service domains often clash with local realities.

In this post, I’ll explore:

1. Why DDD is hard in banking IT.
2. The risks of half-baked DDD implementations.
3. Why BIAN is not a shortcut for domain modeling in Latin America.
4. Real-world examples of successes and failures.

Banks operate in one of the most regulated industries. Every system must comply with:

• Basel III (capital adequacy).
• Anti-Money Laundering (AML) rules.
• GDPR/PII (data protection).
• Local banking laws (e.g., Dodd-Frank, SOX).

Problem: Regulations often dictate system behavior, making it hard to model pure business domains. For example, a "Customer" in DDD terms might be split into:

• KYC-Customer (compliance entity).
• Transactional-Customer (core banking).
• Marketing-Customer (CRM).

This fragmentation leads to anemic domain models where business logic leaks into services rather than residing in entities.

Most banks run on:

1. Mainframes (COBOL, CICS)
2. Monolithic Core Banking Systems (Temenos, Finacle, Flexcube)
3. Batch-processing workflows

Example A European bank tried to implement DDD for a new loan origination system but had to integrate with a 30-year-old mainframe. The "Loan" domain in the new system had to reconcile with:

1. A legacy loan table (denormalized, batch-updated)
2. A risk assessment service (real-time, rules-engine driven)
3. A regulatory reporting module (separate database)

Banking IT is often split into:

1. Core Banking (transactions, ledgers)
2. Risk & Compliance
3. Front Office (Sales, CRM)
4. Payments & Cards

Each silo has its own data models, leading to ubiquitous language breakdowns. For instance:

1. "Account" means a ledger entry in Core Banking but a customer-facing product in Retail Banking.
2. "Transaction" could mean a payment, a securities trade, or a fee adjustment.

Without strong context mapping, teams end up with big balls of mud.

Some teams jump into Aggregates, Value Objects, and Event Sourcing without understanding the core domain.

Real Story: A Latin American bank tried to implement Event Sourcing for its payment system but didn’t account for:

1. Reconciliation requirements (banks must balance books daily).
2. Regulatory audit trails (events alone weren’t sufficient).

They ended up with two systems: an event-sourced one for real-time processing and a SQL-based one for reporting. Double the maintenance cost.

If contexts aren’t well-defined, you get:

1. Duplicate validations (KYC checks in multiple systems).
2. Inconsistent data (customer addresses in CRM vs. Core Banking).
3. High coupling (changes in one system break another).

Example: A bank built a "Customer Onboarding" bounded context but didn’t properly segregate it from "Credit Scoring". When regulations changed, both systems had to be modified—defeating the purpose of DDD.

BIAN is a reference architecture designed to standardize banking capabilities (e.g., "Customer Onboarding," "Loan Processing") into reusable service domains. It aims to:

1. Reduce redundancy in banking software.
2. Improve interoperability between systems.
3. Accelerate digital transformation.

While BIAN provides a useful taxonomy, Latin American banks face unique hurdles:

• Overlap with Local Regulations
  • BIAN’s "Party Risk Assessment" domain assumes GDPR-like rules, but LatAm banks must also handle:
    • Brazil’s LGPD + Central Bank circulars.
    • Argentina’s UIF reporting (stricter than FATF).
  • Example: A Mexican bank adopted BIAN’s "Customer Agreement" domain but had to extend it to track SAT (tax authority) consent flags—a local requirement.
• Legacy System Mismatches:
  • BIAN assumes modular services, but LatAm banks often rely on:
    • Monolithic core systems (e.g., Cobis, BancoPro).
    • Custom fraud checks (e.g., Brazil’s BACEN fraud database).
  • Real Story: A Colombian bank mapped BIAN’s "Payment Execution" to their legacy payment engine… only to discover it couldn’t handle Venezuelan bolivar conversions (a frequent ad-hoc requirement).
• Cultural Nuances in Banking Products:
  • BIAN’s "Deposit Account" domain doesn’t account for:
  • Brazil’s "Poupança" (inflation-adjusted savings).
  • Argentina’s "Plazo Fijo UVA" (USD-linked fixed terms).

False Hope: Some banks believed BIAN would:

• Eliminate domain modeling work (but BIAN is a framework, not a domain model).
• Replace local business logic (yet local tax/currency rules always creep in).

Lesson: BIAN is a reference guide, not a plug-and-play solution.

• Example: Map BIAN’s "Loan Approval" domain to your underwriting rules, but add local risk models (e.g., Brazil’s SCR scoring).

• BIAN’s "Customer Agreement" → LatAm’s "Customer + Tax Compliance" (new context)

• If cross-border payments are your differentiator, model them first—even if BIAN’s "Payment Order" domain feels restrictive.

Latin American banks must:

• Adapt BIAN to local realities (don’t assume 1:1 mappings).
• Model regulatory quirks explicitly (they’re part of the domain!).
• Avoid treating BIAN as a replacement for DDD (it’s a supplement).

Final Thought: BIAN is like a Swiss Army knife—helpful, but you’ll still need a machete for the LatAm jungle.