Composable Banking Architecture: Monolith to Modular

Answer-first: The composable banking architecture pattern replaces monolithic core banking systems with modular, independent Packaged Business Capabilities (PBCs). By leveraging Go microservices, Saga orchestration, and the Strangler Fig migration pattern, banks can decouple their legacy ledgers without risky “Big Bang” cutovers. Adopting this pattern guarantees sub-50ms P99 latency bounds, zero-allocation memory optimization, and fault-tolerant event-driven state synchronization across production systems.

Migration Path from Monolith to Composable

Transitioning to a composable core requires a phased approach to mitigate operational risk:

1. API Gateway & Anti-Corruption Layer (ACL): Shield the legacy core behind a gateway and translate modern API requests into legacy formats using an ACL.
2. Shadow Routing: Deploy the new composable service (e.g., a new Go-based ledger) in parallel. Mirror live traffic to it and reconcile the outputs without affecting actual customer balances.
3. Incremental Cutover (Strangler Fig): Once reconciliation achieves 100% parity, route read traffic to the new service, followed by write traffic, effectively “strangling” that specific domain out of the monolith.

Legacy core banking systems were designed in a different era. Temenos T24, Finacle, and Flexcube shared one defining assumption: the bank’s entire product catalogue — deposits, lending, payments, trade finance — would live inside a single, tightly coupled application and a single, shared database. That assumption held when banking moved at human speed. It breaks completely when product releases need to go from months to days, when a single fraud engine update must not risk a payments outage, and when engineers on a COBOL codebase are retiring faster than they can be replaced.

Composable banking replaces that monolith with a network of independent, purpose-built service components. This post is a deep engineering guide to what that actually means in Go microservices terms: ledger concurrency patterns, event-driven Saga orchestration, BaaS API idempotency, ISO 20022 message flows, and a step-by-step Strangler Fig migration strategy.

For the foundational Saga mechanics in Go, see Dapr Workflow Saga Orchestration Guide and Financial Microservices Architecture: Saga & Ledger.

Composable Banking System Topology

Composable banking is a software design approach that replaces a single-unit core banking system with a network of independent, swappable Packaged Business Capabilities (PBCs). Based on MACH principles (Microservices, API-first, Cloud-native, Headless), it lets a financial institution replace the payment engine without touching the lending module, or launch an embedded finance product line without rebuilding the core ledger.

The topology diagram below outlines the four-layer architectural stack:

graph TD
    EXP["Experience & Channel Layer\n(Mobile, Web, Contact Center, Partner APIs)"]
    ORCH["Integration & Orchestration Layer\n(API Gateway, Kafka, Temporal, BFF)"]
    PBC["Packaged Business Capabilities Layer\n(Ledger, Payments, Lending, KYC, Cards)"]
    INFRA["Cloud Infrastructure Layer\n(Kubernetes, CockroachDB / Spanner, Observability)"]

    EXP --> ORCH
    ORCH --> PBC
    PBC --> INFRA

Each PBC owns its domain completely — its own code repository, its own database, its own deployment pipeline. No shared database. No synchronous cross-domain coupling in the transaction critical path.

BIAN Service Domains and DDD Aggregate Boundaries

The BIAN (Banking Industry Architecture Network) defines ~330 Service Domains — atomic business capabilities like Payment Execution, Current Account, and Customer Agreement. BIAN provides the “what”: a standardized dictionary of capabilities so different vendors and in-house services can interoperate semantically.

Domain-Driven Design (DDD) provides the “how”: each BIAN Service Domain maps to one or more DDD Bounded Contexts, with Aggregates protecting transactional consistency within their boundaries. A Payment Execution domain maps cleanly to an Payment Aggregate that owns the state machine from INITIATED through SETTLED. No other service writes to that state machine directly — it publishes domain events that other contexts react to asynchronously.

The Business Case: Why Legacy Cores Are Breaking Down

Quantify operational licensing costs, delivery lead times, regulatory compliance risks, and technical debt before committing to decomposition:

• TCO: Include license, infrastructure, vendor support, engineering, reconciliation, migration, and dual-run costs. Do not assume a service decomposition lowers the total.
• Time to market: Measure lead time, change failure rate, recovery time, and approval lead time per product line; a distributed architecture can improve one bottleneck while adding others.
• Talent risk: Document succession coverage and critical-system knowledge from the actual support roster rather than applying a generic salary multiple.
• Security posture: Reduce blast radius with least privilege, network segmentation, audit trails, and tested recovery. More services also increase identity, patching, and integration surface area.

The business case is no longer “should we modernize?” It is “what sequence minimizes migration risk?”

Scaling the Core Ledger: Optimistic Locking vs. NewSQL

Traditional monolithic banking ledgers rely on pessimistic row locking (SELECT FOR UPDATE), which creates severe write serialization bottlenecks on high-volume accounts during peak traffic. Composable architectures solve this at two levels:

Level 1: Optimistic Locking on the Account Row

For moderate concurrency, replace the row lock with a version column:

-- Account table with optimistic concurrency
CREATE TABLE accounts (
    id          UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    tenant_id   VARCHAR(50) NOT NULL,
    balance     NUMERIC(18, 4) NOT NULL DEFAULT 0,
    version     INT NOT NULL DEFAULT 1,
    updated_at  TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP
);

-- Optimistic balance update: fails with 0 rows affected if version mismatches
UPDATE accounts
SET    balance    = balance + $1,
       version    = version + 1,
       updated_at = CURRENT_TIMESTAMP
WHERE  id         = $2
AND    version    = $3;  -- stale read returns 0 rows → application retries

In Go, a retry loop with exponential backoff handles version conflicts gracefully. The Go method below demonstrates how to re-read and retry account updates when version mismatches occur:

func (r *AccountRepo) UpdateBalance(ctx context.Context, id uuid.UUID, delta decimal.Decimal, version int) error {
    const maxRetries = 5
    for attempt := 0; attempt < maxRetries; attempt++ {
        result, err := r.db.ExecContext(ctx,
            `UPDATE accounts SET balance = balance + $1, version = version + 1, updated_at = NOW()
             WHERE id = $2 AND version = $3`,
            delta, id, version,
        )
        if err != nil {
            return err
        }
        rows, err := result.RowsAffected()
        if err != nil {
            return err
        }
        if rows == 1 {
            return nil // success
        }
        // Version conflict — re-read and retry
        current, err := r.Get(ctx, id)
        if err != nil {
            return err
        }
        version = current.Version
        time.Sleep(time.Duration(attempt*attempt) * 10 * time.Millisecond) // quadratic backoff
    }
    return ErrVersionConflict
}

Level 2: Append-Only Ledger with Balance Snapshots

For very high-throughput accounts, eliminate balance mutations entirely. Every credit or debit appends a signed delta to an immutable ledger_entries table. The SQL DDL and query below demonstrate how to calculate current balances using append-only ledger entries and periodic snapshots:

-- Append-only ledger entries (never UPDATE or DELETE)
CREATE TABLE ledger_entries (
    id             UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    account_id     UUID NOT NULL,
    transaction_id UUID NOT NULL,
    amount         NUMERIC(18, 4) NOT NULL,  -- positive = credit, negative = debit
    created_at     TIMESTAMPTZ NOT NULL DEFAULT NOW()
);
CREATE INDEX idx_ledger_account_time ON ledger_entries (account_id, created_at DESC);

-- Balance snapshot for fast reads on high-volume accounts
CREATE TABLE balance_snapshots (
    account_id      UUID PRIMARY KEY,
    balance         NUMERIC(18, 4) NOT NULL,
    snapshot_at     TIMESTAMPTZ NOT NULL
);

-- Current balance query (snapshot + deltas since snapshot)
SELECT s.balance + COALESCE(SUM(e.amount), 0) AS current_balance
FROM   balance_snapshots s
LEFT JOIN ledger_entries e
       ON e.account_id = s.account_id
      AND e.created_at > s.snapshot_at
WHERE  s.account_id = $1
GROUP BY s.balance;

Level 3: Distributed NewSQL for Multi-Region Scale

When neither approach is sufficient — multi-region active-active deployments, regulatory data sovereignty across jurisdictions — the ledger migrates to a distributed SQL database:

CockroachDB’s native serializable isolation is particularly relevant: by default, it prevents write-skew (a class of anomaly that Postgres’s default Read Committed isolation allows), which means financial ledger invariants hold without explicit FOR UPDATE locks.

Event-Driven Orchestration: Sagas, Temporal, and the Outbox Pattern

Composable banking microservices each own their own database. A fund transfer spanning a debit service, a fraud check service, and a credit service cannot rely on a single database transaction. The Saga pattern solves this with a sequence of local transactions, where each step has a corresponding compensating transaction that undoes its effect if a later step fails.

Orchestration vs. Choreography for Financial Flows

Choreography (services reacting to events with no central coordinator) works for simple, low-step flows. For banking, orchestration is mandatory:

Temporal Workflow for a Fund Transfer Saga

Temporal replays the event log from the last checkpoint so completed activities return cached results without re-executing. For a deep analysis of code mechanics, see Temporal Saga Implementation Guide. The Go workflow function below details the Fund Transfer Saga orchestrator:

// FundTransferWorkflow is the Saga orchestrator — MUST be deterministic.
// No time.Now(), no rand, no environment reads inside this function.
func FundTransferWorkflow(ctx workflow.Context, input FundTransferInput) (FundTransferResult, error) {
    ao := workflow.ActivityOptions{
        StartToCloseTimeout: 30 * time.Second,
        RetryPolicy: &temporal.RetryPolicy{
            MaximumAttempts:    3,
            InitialInterval:    time.Second,
            BackoffCoefficient: 2.0,
        },
    }
    ctx = workflow.WithActivityOptions(ctx, ao)

    // Step 1: Debit source account
    var debitResult DebitResult
    if err := workflow.ExecuteActivity(ctx, DebitSourceAccount, input).Get(ctx, &debitResult); err != nil {
        return FundTransferResult{}, fmt.Errorf("debit failed: %w", err)
    }

    // Step 2: Fraud check
    var fraudResult FraudCheckResult
    if err := workflow.ExecuteActivity(ctx, CheckFraud, input).Get(ctx, &fraudResult); err != nil || fraudResult.Flagged {
        // Compensate: reverse the debit
        _ = workflow.ExecuteActivity(ctx, ReverseDebit, debitResult).Get(ctx, nil)
        return FundTransferResult{}, ErrFraudFlagged
    }

    // Step 3: Credit target account
    var creditResult CreditResult
    if err := workflow.ExecuteActivity(ctx, CreditTargetAccount, input).Get(ctx, &creditResult); err != nil {
        // Compensate: reverse the debit
        _ = workflow.ExecuteActivity(ctx, ReverseDebit, debitResult).Get(ctx, nil)
        return FundTransferResult{}, fmt.Errorf("credit failed: %w", err)
    }

    return FundTransferResult{
        TransactionID: input.TransactionID,
        Status:        "SETTLED",
        SettledAt:     workflow.Now(ctx), // deterministic time from Temporal runtime
    }, nil
}

The Transactional Outbox: Preventing Data Drift

After a local database write, the service must also publish an event to Kafka so downstream services react. Writing to both the database and Kafka in the same operation is the Dual-Write problem: if Kafka is unavailable after the database write succeeds, the event is lost and the Saga stalls with no way to detect the gap.

The Transactional Outbox pattern guarantees that local database writes and event stream publications commit atomically. The SQL DDL below defines an outbox_events table co-located in the domain database:

-- Outbox table lives in the same database as the domain table
CREATE TABLE outbox_events (
    id           UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    aggregate_id UUID NOT NULL,
    event_type   VARCHAR(100) NOT NULL,
    payload      JSONB NOT NULL,
    published    BOOLEAN NOT NULL DEFAULT FALSE,
    created_at   TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

The Go method below demonstrates how to execute account balance deductions and outbox event insertions within a single database transaction:

// In a single database transaction: write business data + event payload atomically
func (s *AccountService) DebitAccount(ctx context.Context, tx *sql.Tx, input DebitInput) error {
    // 1. Update the account balance
    _, err := tx.ExecContext(ctx,
        `UPDATE accounts SET balance = balance - $1 WHERE id = $2`, input.Amount, input.AccountID)
    if err != nil {
        return err
    }

    // 2. Insert the outbox event — same transaction, same commit
    payload, _ := json.Marshal(AccountDebitedEvent{
        AccountID: input.AccountID,
        Amount:    input.Amount,
        TxID:      input.TransactionID,
    })
    _, err = tx.ExecContext(ctx,
        `INSERT INTO outbox_events (aggregate_id, event_type, payload) VALUES ($1, $2, $3)`,
        input.AccountID, "account.debited", payload)
    return err
}

Debezium reads the PostgreSQL WAL and forwards every outbox_events INSERT directly to Kafka, with zero polling overhead and guaranteed at-least-once delivery. Even if Kafka is down during the database commit, Debezium will forward the event once Kafka recovers.

For a complete walkthrough of the broader event-driven patterns powering this approach, see Mastering Event-Driven Architecture with Dapr. For the observability layer across these banking microservices — W3C trace propagation, OTel Collector sampling, and tracing Kafka consumers — see Go Microservices Distributed Tracing Architecture.

BaaS API Design: Idempotency and ISO 20022 Integration

Banking-as-a-Service APIs are consumed by fintechs over unreliable networks. A payment initiation request that times out at the client side may have already been processed server-side. The client retries and — without proper protection — the customer is charged twice.

Idempotency Key Implementation in Go

Every state-mutating BaaS endpoint must accept a client-generated idempotency key (UUID v4) and store a hash of it alongside the processing result. The Go HTTP handler below implements idempotency key verification using SHA-256 key hashing:

// idempotencyMiddleware checks for duplicate requests before processing.
// The key_hash has a UNIQUE constraint in the database.
func (h *PaymentHandler) InitiateTransfer(w http.ResponseWriter, r *http.Request) {
    idempotencyKey := r.Header.Get("Idempotency-Key")
    if idempotencyKey == "" {
        http.Error(w, "Idempotency-Key header required", http.StatusBadRequest)
        return
    }

    // SHA-256 hash prevents key enumeration attacks
    hash := sha256.Sum256([]byte(r.Header.Get("X-Client-ID") + ":" + idempotencyKey))
    keyHash := hex.EncodeToString(hash[:])

    // Claim the key. Only the request that inserts a row may perform the side effect.
    var claimed string
    err := h.db.QueryRowContext(r.Context(), `
        INSERT INTO idempotency_keys (key_hash, status, created_at)
        VALUES ($1, 'PROCESSING', NOW())
        ON CONFLICT (key_hash) DO NOTHING
        RETURNING key_hash`,
        keyHash,
    ).Scan(&claimed)
    if err != nil && !errors.Is(err, sql.ErrNoRows) {
        http.Error(w, "database error", http.StatusInternalServerError)
        return
    }

    if claimed == "" {
        // A concurrent request must never re-run a payment. Return a completed
        // result, or a retriable in-progress response with a status endpoint.
        status, err := h.lookupIdempotencyStatus(r.Context(), keyHash)
        if err != nil {
            http.Error(w, "database error", http.StatusInternalServerError)
            return
        }
        if status == "COMPLETED" || status == "FAILED" {
            h.returnCachedResult(w, keyHash)
            return
        }
        w.Header().Set("Retry-After", "2")
        http.Error(w, "payment is still processing", http.StatusConflict)
        return
    }

    // Process the new payment and update the idempotency record
    h.processPaymentAndUpdateKey(w, r, keyHash)
}

ISO 20022 Message Flow

BaaS payment APIs map to ISO 20022 XML messages at the interbank layer. Understanding this mapping is essential when debugging payment failures at the settlement layer:

The pain.001 → pacs.008 transformation is a critical data mapping step: the pain message carries debtor intent (what the customer wants), while the pacs message carries the interbank instruction. Validate mapping, retention, and reconciliation requirements against the payment scheme and jurisdiction; this article is not compliance advice.

Verification of Payee (VoP) API Integration

Under the EU Instant Payments Regulation, SEPA PSPs must verify payee identity before executing credit transfers. The EPC VoP Inter-PSP API returns one of four matching codes:

The CMTC response is the most operationally complex: the API returns the actual registered name alongside the close-match indicator. Your UI must present this name clearly so the payer can confirm they are paying the right person — this is the primary fraud-prevention mechanism.

Security Gates: RFC 8705 mTLS and DORA Compliance

Enforcing bank-grade security across composable banking interfaces demands strict adherence to Financial-grade API standards and regulatory resilience frameworks. Implementing mutual-TLS certificate-bound access tokens alongside threat-led penetration testing protocols ensures that sensitive inter-bank communications and third-party BaaS integrations remain protected against token hijacking and system-wide vulnerabilities.

RFC 8705: Certificate-Bound Access Tokens

Standard OAuth 2.0 Bearer tokens can be stolen and replayed from a different client. The Financial-grade API (FAPI) 1.0 Advanced profile addresses this with RFC 8705 Mutual-TLS Client Certificate-Bound Access Tokens: the access token is cryptographically bound to the client’s X.509 certificate, making stolen tokens useless without the corresponding private key.

The sequence diagram below traces the RFC 8705 mTLS token binding validation flow. It details how the API Gateway verifies the SHA-256 certificate thumbprint against the token payload before forwarding client requests:

sequenceDiagram
    participant C as Fintech Client
    participant GW as API Gateway
    participant AS as Authorization Server

    C->>AS: mTLS handshake + Client Credentials Grant
    AS->>AS: Bind token to client cert SHA-256 thumbprint
    AS-->>C: access_token { cnf: { x5t#S256: "<thumbprint>" } }

    C->>GW: POST /payments (Bearer token + mTLS connection)
    GW->>GW: Extract client cert from TLS session
    GW->>GW: Compute SHA-256(cert) → compare to cnf claim
    alt Thumbprints match
        GW->>GW: Forward request to Payment Service
    else Mismatch (stolen token)
        GW-->>C: 401 Unauthorized
    end

For mobile and SPA clients where establishing mTLS is architecturally impractical, DPoP (RFC 9449) provides an equivalent proof-of-possession guarantee at the application layer: the client signs each request with a private key, and the server verifies that the signed request matches the DPoP public key bound in the access token.

DORA: Threat-Led Penetration Testing

The Digital Operational Resilience Act (DORA, enforceable from January 17, 2025) requires significant financial institutions to conduct Threat-Led Penetration Testing (TLPT) at least every three years. TLPT is not a standard pen test: it mimics real-world adversary TTPs (Tactics, Techniques, Procedures), typically following the TIBER-EU framework, and covers all critical ICT functions including outsourced cloud infrastructure.

A single TLPT exercise spans 6-12 months including scoping, red team execution, and remediation. For composable banking systems, TLPT scope must include the API Gateway, the event bus (Kafka), the orchestration layer (Temporal/Dapr), and every critical PBC. Third-party SaaS vendors (core banking platforms, cloud providers) are in scope if they support critical functions.

The Strangler Fig Migration: De-Risking Core Modernization

The highest-risk core banking transformation is the “Big Bang” cutover: freeze the legacy system, build the new platform in parallel, and switch everything on a single date. This approach fails consistently because the new system’s edge cases are discovered only under production load, after the rollback window has closed.

The architecture diagram below illustrates the Strangler Fig migration pipeline for legacy core banking systems. It highlights how an API Gateway and Anti-Corruption Layer (ACL) shift live domain traffic incrementally to modern Go PBCs:

graph LR
    CLIENT["Client Requests"] --> GW["API Gateway\n(Kong / Apigee)"]
    GW -->|"New domain requests"| NEW["Modern PBCs\n(Go microservices)"]
    GW -->|"Legacy domain requests"| ACL["Anti-Corruption Layer"]
    ACL --> LEGACY["Legacy Core\n(Temenos T24 / Finacle)"]
    NEW --> KAFKA["Kafka Event Bus"]
    LEGACY --> KAFKA
    KAFKA --> RECON["Reconciliation Engine"]

Phase 1: Place the Gateway and Anti-Corruption Layer

Before migrating any domain, position an API Gateway in front of the legacy core. All traffic now flows through the gateway, which routes 100% of requests to the legacy system. The gateway becomes the control plane for traffic shifting.

The Anti-Corruption Layer (ACL) lives between the gateway and the legacy core. The Go code snippet below demonstrates how the ACL translates domain payment requests into legacy T24 transaction formats:

// ACL translates a modern PaymentRequest into the legacy T24 transaction format
type T24ACL struct {
    legacyClient *T24Client
}

func (a *T24ACL) InitiatePayment(ctx context.Context, req domain.PaymentRequest) (domain.PaymentResult, error) {
    // Translate modern domain model → legacy T24 format
    t24Req := T24PaymentRequest{
        FTNO:    req.TransactionID,
        DEBIT:   req.SourceAccount.T24AccountID,
        CREDIT:  req.TargetAccount.T24AccountID,
        AMT:     req.Amount.String(),
        CCY:     req.Currency.ISO4217(),
        VDATE:   req.ValueDate.Format("020106"), // T24 date format
    }

    t24Resp, err := a.legacyClient.PostTransaction(ctx, t24Req)
    if err != nil {
        return domain.PaymentResult{}, translateT24Error(err)
    }

    // Translate legacy response → clean domain model
    return domain.PaymentResult{
        TransactionID: req.TransactionID,
        Status:        mapT24Status(t24Resp.Status),
        CompletedAt:   parseT24Date(t24Resp.PostingDate),
    }, nil
}

Phase 2: Shadow Routing for Risk-Free Validation

Before switching live traffic to a new PBC, deploy it in shadow mode. The Istio VirtualService YAML below demonstrates how to configure traffic mirroring to send live request copies to a shadow service without affecting production responses:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: payment-service
spec:
  hosts: ["payment-service"]
  http:
  - route:
    - destination:
        host: payment-service-legacy
        port:
          number: 8080
      weight: 100
    mirror:
      host: payment-service-new        # shadow receives copy of every request
      port:
        number: 8080
    mirrorPercentage:
      value: 100.0                      # mirror 100% of traffic

The shadow responses are logged but discarded — users are served from the legacy system. The reconciliation engine compares shadow responses against legacy responses and alerts on any divergence. Only when the divergence rate drops to zero for 30+ days does traffic shift begin.

Phase 3: Reconciliation Loops for Data Parity

During the dual-run period, a continuous reconciliation engine validates that account balances match across systems. The Go implementation snippet below illustrates how to execute automated balance comparison checks between legacy and modern ledgers:

func (r *ReconciliationEngine) RunBalanceCheck(ctx context.Context) error {
    accounts, err := r.listActiveAccounts(ctx)
    if err != nil {
        return err
    }

    var discrepancies []Discrepancy
    for _, account := range accounts {
        legacyBalance, err := r.legacyClient.GetBalance(ctx, account.LegacyID)
        if err != nil {
            continue
        }
        modernBalance, err := r.modernLedger.GetBalance(ctx, account.ModernID)
        if err != nil {
            continue
        }

        if legacyBalance.Amount.Compare(modernBalance.Amount) != 0 {
            discrepancies = append(discrepancies, Discrepancy{
                AccountID:     account.ID,
                LegacyBalance: legacyBalance.Amount,
                ModernBalance: modernBalance.Amount,
                Delta:         legacyBalance.Amount.Sub(modernBalance.Amount),
                DetectedAt:    time.Now(),
            })
        }
    }

    if len(discrepancies) > 0 {
        r.alertOps(ctx, discrepancies)
        return r.storeDiscrepancies(ctx, discrepancies)
    }
    return nil
}

Next-Gen Core Banking Vendor Breakdown

For teams evaluating off-the-shelf composable cores before building in-house, the microfinance vertical offers a useful contrast: it shares the same double-entry ledger and Saga requirements but operates on high-frequency, low-value group loans — see Microfinance Core Banking Architecture for that lens.

Key differentiators:

• Thought Machine is the only vendor exposing its product configuration engine as Python code. Banks write smart contracts that define product lifecycle rules (interest accrual, fee triggers, account state transitions) in Python, which the Vault runtime executes on event hooks. This gives engineering teams genuine programmable control without forking the core platform.
• Finxact chose Go for its microservices runtime — the same language most backend teams in this audience use for their own services. Its temporal PostgreSQL schema stores every record with valid-time and transaction-time context, enabling point-in-time queries across the entire ledger history without separate audit tables.
• Mambu’s database-per-tenant model (separate MySQL RDS instance per bank customer) provides strong data isolation at the cost of higher infrastructure overhead. This is the highest compliance-friendly model for regulated institutions that cannot tolerate shared schema data co-mingling.

Frequently Asked Questions

Addressing technical questions regarding composable architecture topologies, Strangler Fig migration strategies, Saga orchestration, and BaaS API security helps financial engineering teams modernize legacy core systems safely. The following detailed Q&A pairs detail essential operational principles for building scalable, compliant, and modular banking platforms.

Q1: What is composable banking architecture?

Composable banking architecture replaces a monolithic core banking system with a network of independent, domain-specific Packaged Business Capabilities (PBCs). Each PBC owns its own database, deployment pipeline, and API surface. The system is governed by MACH principles (Microservices, API-first, Cloud-native, Headless) and typically aligns service boundaries with BIAN industry-standard Service Domains.

Q2: Why are banks migrating away from monolithic core banking systems?

Three common pressures are cost, talent concentration, and delivery speed. Their size and remediation depend on the institution; use a measured baseline and a regulated change plan before committing to a modernization program.

Q3: What is the Strangler Fig pattern in core banking migration?

The Strangler Fig pattern migrates a monolithic system domain-by-domain without a “Big Bang” cutover. An API Gateway routes traffic, initially forwarding everything to the legacy system. New microservices intercept individual domains (e.g., cards, deposits) as they become production-ready. An Anti-Corruption Layer translates between modern domain models and legacy data formats. Shadow routing validates the new service against the legacy system before any live traffic shifts.

Q4: What is the difference between Temporal and Dapr Workflow for banking Sagas?

Both implement Orchestrated Sagas using Event Sourcing Replay for crash recovery. Temporal is preferred for complex, long-running workflows requiring advanced versioning, custom search attributes, and high workflow throughput at scale. Dapr Workflow is lighter and integrates natively with the broader Dapr sidecar ecosystem (Pub/Sub, State, Bindings), making it the better fit for teams already using Dapr for other microservice concerns.

Q5: What is RFC 8705 and why does it matter for BaaS APIs?

RFC 8705 defines Mutual-TLS Client Certificate-Bound Access Tokens for OAuth 2.0. The Authorization Server binds the access token to the client’s X.509 certificate by embedding the certificate’s SHA-256 thumbprint in the token’s cnf.x5t#S256 claim. The API Gateway validates that the token thumbprint matches the certificate presented in the current mTLS connection, making stolen tokens unusable without the corresponding private key. This is mandatory for Financial-grade API (FAPI) 1.0 Advanced compliance.

Q6: What does DORA require for banks running composable banking systems?

DORA (Digital Operational Resilience Act, enforceable January 2025) requires significant EU financial institutions to conduct Threat-Led Penetration Testing (TLPT) at least every three years. TLPT follows the TIBER-EU framework, mimicking real adversary TTPs against all critical ICT functions — including the API Gateway, event bus, orchestration layer, and third-party SaaS core banking platforms. A single TLPT exercise typically spans 6-12 months.