Customer & KYC
Create customers, capture identity data and model screening outcomes such as PEP, sanctions and adverse-media review.
Case study · AI-native banking
Dummy Bank
A hands-on core banking environment that combines deterministic financial services with a governed AI knowledge and operations layer.
The idea
Learn banking by operating a bank-shaped system.
I originally built Dummy Bank as a safe environment for learning the mechanics behind customer onboarding, KYC, accounts and payments. Most banking material explains concepts in isolation. I wanted something closer to the real implementation experience: connected journeys, APIs, state changes, exceptions and operational consequences.
The project is now evolving into an AI-native core banking concept. “AI-native” does not mean allowing a language model to change a balance or approve a payment. The ledger and transaction rules remain deterministic. AI is used where it is strongest: retrieving institutional knowledge, explaining context, helping investigate exceptions and making complex workflows easier to understand.
The financial core must be predictable. The intelligence around it should make people faster, better informed and easier to audit.
Target architecture
A deterministic core with an intelligence layer.
The architecture separates transaction authority from AI assistance. Every action that changes financial state travels through authenticated domain services and explicit controls. The AI layer can retrieve, explain and recommend; it cannot silently write to the ledger.
Customer appOperations consolePartner APIs
Authenticated journeys & explicit permissionsAI copilotKnowledge retrievalMCP tools
Evidence, policy and human approvalCustomer & KYCAccounts & ledgerPaymentsAudit events
Banking capabilities
Built around end-to-end journeys.
Products & accounts
Configure products, open accounts and expose balances and transaction history through clear service boundaries.
Payments
Initiate and track payment journeys with explicit business states, validation, rejection reasons and idempotent processing.
Operations
Surface exceptions, reconciliation evidence, audit events and the runbooks needed to understand what the platform is doing.
Why the boundaries matter
My core-banking implementation experience has taught me that the ledger is rarely the hardest part. Risk accumulates at the boundaries: who owns customer state, how retries work, what happens after a partial failure and how an exception reaches operations. Dummy Bank makes those boundaries visible rather than hiding everything behind a happy-path demonstration.
AI knowledge layer
From documents and cases to grounded assistance.
In my article on an AI tool for support organisations, I explored a local RAG and LLM workflow using Jira and Confluence data, embeddings, LanceDB and a locally hosted model. Dummy Bank applies the same pattern to banking knowledge: product rules, API documentation, implementation decisions, runbooks, prior incidents and synthetic support cases.
The aim is not a chatbot that confidently invents an answer. The assistant retrieves semantically relevant evidence, respects the user’s access boundary and presents sources beside its recommendation. A support analyst could ask why a payment was rejected; an implementation consultant could ask which fields are required for a product configuration; an operator could retrieve the runbook associated with a failed integration.
01Banking knowledgeProduct rules · Jira cases · runbooks · API docs
→02Transform & embedChunking · metadata · vector representation
→03Permission-aware retrievalSemantic search · tenant and role filters
→04Grounded responseAnswer · sources · confidence · next action
Agent-ready integration
MCP as a controlled doorway—not a master key.
My filesystem MCP experiment demonstrated a simple idea: an AI client becomes more useful when it can reach tools and context through a standard protocol. In Dummy Bank, the same approach could expose carefully scoped capabilities such as searching product documentation, retrieving a synthetic customer journey or explaining an exception.
Read tools can be broad enough to support investigation. Actions that create a customer, change configuration or initiate a payment should require narrow scopes, validation and explicit human confirmation. Every call should produce an audit event.
AI client or operations copilot→Authenticated MCP server→Scoped banking tools→Policy check + audit trail
Guardrails
What makes the AI layer bankable.
Evidence before fluency
Operational recommendations should cite the product rule, historical case or runbook used to form the answer. If there is no reliable evidence, the assistant should say so.
Access before retrieval
Customer and operational knowledge cannot be treated as one public corpus. Tenant, role and data-classification filters must be applied before documents reach the model.
Human authority over financial state
AI can explain a failed payment or prepare an action. Deterministic services, policy checks and authorised people decide whether the action is executed.
Observable by design
Prompts, retrieved evidence, tool calls and human approvals need correlation references so an operator can reconstruct how a recommendation became an action.
Why it matters
A learning platform—and a point of view on AI-native banking.
Dummy Bank lets me test ideas across the complete lifecycle: product configuration, implementation, integration, production operations and support. It connects my experience delivering core banking platforms with my hands-on work in AWS, RAG, local models and MCP.
The larger point is that an AI-native bank should not be a language model wrapped around a ledger. It should be a well-controlled banking platform where intelligence is available at every decision point, grounded in evidence and constrained by the same permissions and audit expectations as the rest of the system.
Read: Core banking succeeds at the boundaries →Read: AI tool for Support organisation ↗Read: Claude Client with Filesystem MCP Server ↗