The AI-Enabled Digital Bank Is Not a Layer Cake

FinTech Engineering

A familiar target-state diagram puts channels at the top, APIs and orchestration in the middle, core banking and payments underneath, then data, AI, governance, and observability across the bottom. It is a useful inventory. It shows that a digital bank needs more than a mobile app and a core ledger.

But it is not yet an architecture a team can execute.

My test is simple: point at a customer action and ask who is authorised to decide, which system creates the financial fact, what happens after a timeout, which evidence proves the outcome, and how the bank recovers the critical service. If the diagram cannot answer those questions, its layers are categories—not contracts.

An AI-enabled bank needs two connected paths. The first turns customer intent into an authorised, durable outcome. The second turns observed outcomes into governed data and model proposals. AI may improve the decision, but it must not blur the boundary between a proposal and a permitted financial effect.

Start with the operation, not the platform

“Real-time, intelligent, scalable, secure, resilient” sounds right because no one wants the opposite. It is still too vague to guide design.

The Basel Committee’s operational-resilience principles start from critical operations and a bank’s ability to withstand disruptive events. That changes the architecture discussion. Instead of asking whether Kafka, Kubernetes, or a service mesh is highly available, I ask:

• Which customer or market outcome must continue?
• What level of disruption can the bank tolerate?
• Which people, processes, technology, data, facilities, and third parties support it?
• How does the bank detect that the operation is outside tolerance?
• What degraded mode is safe?

Take a card-limit increase requested through a conversational assistant. The critical outcome is not “the chatbot replies.” It is that an authenticated customer receives a correct, authorised decision; any approved limit is recorded once; the change is visible to fraud, servicing, statements, and audit; and the bank can explain or reverse the effect under the applicable rules.

That one operation crosses the channel, identity, product, decision, core-record, event, data, AI, and control concerns shown in a layer diagram. Designing each layer independently will not guarantee the outcome.

Replace boxes with six enforceable contracts

I use six contracts to turn the capability inventory into a delivery architecture.

1. The authority contract

The authority contract answers who or what may request an action, for which resource, under which purpose, scope, limit, and time window.

In the UAE, the CBUAE Open Finance Regulation makes the separation tangible. The framework includes an API Hub and Trust Framework; data sharing and service initiation are subject to explicit user consent, appropriate authentication, and secure communication. These are not decorative features of an API gateway. They are part of the business authority for an action.

The same reasoning applies inside the bank. NIST’s Zero Trust Architecture rejects implicit trust based only on network location. A request from an “internal” service is not authorised merely because it crossed the service mesh. User identity, workload identity, protected resource, requested operation, policy, and current context still matter.

An API gateway can validate a token and rate limit traffic. It cannot decide every product entitlement, financial limit, segregation-of-duties rule, or exceptional approval. The target state must show where those decisions live and how their evidence travels with the command.

2. The capability-ownership contract

A box labelled “microservices” says nothing about ownership. A banking capability needs a bounded vocabulary, commands it owns, invariants it enforces, records it controls, and service outcomes for which one team is accountable.

BIAN’s banking service landscape is useful here because it gives teams a banking-specific vocabulary for decomposing capabilities and service domains. It should inform the map, not become a reason to generate hundreds of services. The deployable boundary should follow a stable business responsibility and its consistency needs—not one rectangle per reference-model term.

For the limit-increase example, the assistant does not own the limit. A product or credit capability owns the command, validates the account state, applies the policy decision, enforces idempotency, and records the approved change. The model may help interpret the request or propose an amount. Ownership remains with the domain.

3. The financial-truth contract

Layer diagrams often use “single source of truth” beside a lake, warehouse, or customer-360 platform. In banking, that phrase becomes dangerous when it collapses different kinds of truth.

The ledger records balanced financial facts. A product system records contractual state. A payment rail supplies external settlement evidence. An event log records that a producer announced something. A warehouse provides governed analytical views. None is a universal replacement for the others.

The BCBS 239 principles require more than central storage: integrated taxonomies and architecture, metadata, identifiers, ownership, quality, and the ability to support risk-data aggregation during stress. A data lake icon does not satisfy those responsibilities.

For every important number, the architecture should identify its authoritative producer, business meaning, effective time, correction mechanism, lineage, and reconciliation control. “Customer balance” alone is not precise enough. Available balance, ledger balance, settled balance, and an analytical daily snapshot can be correct at the same time while answering different questions.

4. The event contract

An event-streaming layer can decouple producers from consumers, but it can also become a shared ambiguity bus.

An event needs a named owner, versioned schema, business key, ordering assumption, event time, publication guarantee, retention policy, privacy classification, and a replay contract. Consumers need to know whether the event reports an accepted command, a committed domain fact, or an observation that may later be corrected.

I avoid using an event as the only proof of a financial outcome. The domain first commits its durable state and an outbox record within the appropriate transaction boundary. Publication can then be retried. Consumers remain idempotent. Reconciliation compares the source record, emitted event, downstream record, and—where relevant—external rail evidence.

This is the difference between “event driven” as a transport preference and event-driven architecture as an explicit consistency model.

5. The AI-decision contract

Putting an “AI/ML layer” below the data platform suggests every model is a shared utility. The risk and latency profile actually depend on the decision.

Fraud scoring before authorisation, document classification during onboarding, a next-best-action recommendation, and a generative servicing assistant do not have the same authority, evidence, or failure mode. Each needs a decision contract:

The NIST AI Risk Management Framework treats trustworthiness as a lifecycle concern spanning design, development, use, and evaluation. The Financial Stability Board’s June 2026 report on sound practices for responsible AI adoption similarly proposes organisation-wide governance across the AI lifecycle. That FSB document is a consultation, not a final binding rule, but its framing is useful: adding a model endpoint is not the same as governing an AI-enabled capability.

My default boundary is therefore: the model proposes; deterministic controls and authorised domain capabilities create effects. A low-risk use case may automate within narrow delegated limits. A material or uncertain case may require human approval. Both paths should record the same decision evidence.

6. The evidence-and-resilience contract

Governance and observability should not be drawn only as foundations at the bottom. They must intersect the live path.

For one request, I want to correlate customer intent, consent, authentication, policy decision, domain command, idempotency key, model and prompt version, retrieval evidence, financial or business record, emitted events, downstream processing, and customer-visible outcome.

OpenTelemetry’s observability model describes traces, metrics, and logs as signals used to understand internal system state from its outputs. In a bank, technical telemetry needs business context without leaking sensitive data. A trace that proves an HTTP call completed is useful; a control record that proves which authorised command created a financial effect is different and equally necessary.

The contract also defines failure behavior. If the model is unavailable, does the bank fall back to deterministic rules, route to a person, or stop the operation? If an event stream is delayed, can the source capability continue safely? If the customer loses the connection after submission, can the channel retrieve the durable outcome without creating the command twice?

Walk the request from intent to evidence

Return to the limit-increase example.

1. The channel captures the customer’s intent and presents the required disclosure.
2. Identity, consent, session risk, and product scope establish what may be requested.
3. The assistant extracts a structured proposal. It does not call a database or mutate an account directly.
4. The decision service evaluates governed data and records the model, feature, rule, and evidence versions.
5. Deterministic policy checks eligibility, exposure, delegated limits, and whether human approval is required.
6. The product capability accepts one idempotent command, enforces its invariant, and records the result.
7. Events publish the committed outcome for fraud, servicing, notification, analytics, and regulatory processes.
8. Telemetry and control evidence show the end-to-end result; later outcomes return to a governed data product for evaluation and improvement.

Notice what is not in this sequence: an LLM with broad credentials choosing arbitrary tools. Tool access should be narrow, typed, policy-controlled, and auditable. The AI context should not contain reusable credentials or final authority.

A target state also needs a transition state

A beautifully layered end state can hide the hardest question: how does the bank move without breaking a critical operation?

I would not begin with a programme to “build the API layer,” “move to microservices,” or “create the AI platform.” I would choose one bounded operation with measurable pain and build a vertical slice.

For example:

1. Map the current limit-change journey, systems of record, approvals, failure modes, and control evidence.
2. Define the future authority, capability, truth, event, AI, and resilience contracts for that operation.
3. Put a stable API and idempotent command boundary around the current product system.
4. Add end-to-end identity, policy, telemetry, and reconciliation before changing the implementation behind the boundary.
5. Introduce the AI proposal path in shadow mode and compare it with approved outcomes.
6. Automate only the cases that meet evaluation and delegated-authority thresholds.
7. Prove recovery and degraded operation, then expand to the next capability.

This approach produces reusable platform capabilities, but each one is earned by a real journey. It also exposes whether the supposed target architecture supports delivery or merely reorganises the technology catalogue.

The architecture review I would run

I would ask every team to complete this scorecard for one critical operation:

If a row is answered with only a product name, the design is not finished.

The layer cake still has a place

Layered reference diagrams remain useful. They create a shared vocabulary, expose missing capabilities, and help explain investment areas. A central API, data, or AI platform can also reduce duplicated controls and improve consistency.

The trade-off is concentration. A universal orchestration layer can become the owner of no business outcome and the failure domain of every outcome. A customer-360 platform can become a stale copy mistaken for a system of record. A shared model gateway can standardise access while hiding use-case-specific evaluation and authority.

The answer is not to reject platforms. It is to make their contracts explicit and keep domain accountability visible.

My decision rule

An AI-enabled digital bank is not defined by the presence of an LLM box, an event bus, or a data lake. It is defined by how safely and observably it turns intent into a permitted, durable outcome—and how it learns from that outcome without surrendering authority or financial truth.

Use the layer diagram as the capability map. Use critical operations, contracts, sequences, failure modes, and evidence to create the architecture.

The model may propose. The bank must still authorise, execute, record, reconcile, explain, and recover.

Related reading

• Responsible AI Governance as an Engineering System
• Designing an Event-Driven Ledger That Auditors Can Trust
• Platform Engineering Golden Paths Without Golden Cages

References

• CBUAE — Open Finance Regulation: Introduction and Scope
• CBUAE — Open Finance Regulation
• Basel Committee — Principles for operational resilience
• Basel Committee — Principles for effective risk data aggregation and risk reporting
• NIST — Zero Trust Architecture, SP 800-207
• NIST — AI Risk Management Framework
• Financial Stability Board — Sound Practices for Responsible Adoption of AI, consultation report
• BIAN — Banking Industry Architecture Network
• OpenTelemetry — Observability primer