Every bank board has had the AI conversation by now. The pressure is real, the vendor pitches are relentless, and the fear of falling behind competitors is a powerful motivator. What's less discussed in those boardroom conversations is the gap between an AI pilot that impresses in a demo and an AI system that survives contact with production traffic, a regulator's questions, and three years of model drift. 

That gap is not a failure of ambition. It's the natural distance between a proof of concept and an operational system that has to be explainable, auditable, and reliable under load. For institutions deciding where to place their next budget cycle, understanding that distance matters more than any vendor's roadmap slide. 

Fraud detection is the clearest production success story in banking AI, and for good reason: the problem has abundant labeled data, a tolerance for probabilistic scoring rather than binary certainty, and a feedback loop that improves the model over time. Transaction-level anomaly detection, behavioral biometrics, and network-based fraud graphs are widely deployed in production across many large banks, including European institutions, not merely as pilots but as core fraud prevention infrastructure. The economics are straightforward — every fraudulent transaction caught has a direct, measurable value, which makes the business case easy to defend internally. 

Document processing is the second real win. Extracting structured data from loan applications, KYC documentation, and trade finance paperwork is a task AI now handles with meaningfully lower error rates than manual review, particularly when paired with a human-in-the-loop verification step for edge cases. This isn't glamorous work, but it's exactly the kind of high-volume, rules-adjacent task where AI's strengths — pattern recognition across large unstructured inputs — map cleanly onto the problem. 

Customer support routing and triage has also moved past the hype phase. Classifying incoming queries, drafting initial response suggestions for human agents, and identifying escalation-worthy interactions are all in stable production use. The key design choice that separates the systems that work from the ones that don't: AI assists the routing and drafting, but a human retains authority over anything customer-facing or financially consequential. 

Risk scoring is more mixed, and worth treating separately from fraud detection. Credit risk and counterparty risk models augmented with AI are in production, but almost always as a layer on top of — not a replacement for — traditional statistical scoring models. The reason is regulatory, not technical: model risk management frameworks under EBA guidelines require a level of explainability that many modern AI approaches don't natively provide, which shapes how these systems get architected in practice. 

Fully autonomous decisioning in anything touching credit, AML, or regulatory reporting remains largely aspirational at institutional scale. The vendor pitch of "AI that approves loans end-to-end" undersells the explainability requirement that sits underneath every credit decision a bank makes. Until a model can produce a decision rationale that satisfies both an internal model risk committee and an external auditor, full autonomy in this category stays a pilot, not a product. 

General-purpose conversational AI as a primary customer channel is another area where enthusiasm has outrun engineering maturity. The demos are impressive. The production reality — hallucination risk in a regulated financial context, the difficulty of bounding what the system will and won't say about products, rates, or advice — means most banks that have shipped this are running it in narrowly scoped, tightly guardrailed configurations, not as an open-ended assistant. 

Real-time, model-driven regulatory reporting is frequently pitched but rarely production-grade. The latency and consistency requirements for regulatory submissions leave little room for the probabilistic outputs of current AI systems, and the cost of an error is asymmetric — a missed or malformed submission has consequences a false positive in a fraud queue does not. 

The Engineering Constraints That Decide the Outcome 

The line between production-ready and perpetual pilot usually comes down to four constraints, and it's worth naming them plainly for anyone evaluating a proposal: 

Latency. Fraud detection at the point of transaction has a latency budget measured in milliseconds. Many AI approaches that perform well in batch or offline evaluation simply don't meet that budget without significant re-architecture — a gap that shows up only once a system is under real load, not in a proof of concept. 

Explainability. Every AI system touching a credit, risk, or compliance decision inherits the explainability obligations of the process it's embedded in. This is where EU AI Act classifications become directly relevant: many banking use cases — credit scoring among them — fall into high-risk categories that carry explicit transparency and human oversight requirements. Explainability isn't a nice-to-have layered on later; it has to be designed in from the first architectural decision. 

Data quality. AI systems trained or fine-tuned on inconsistent, siloed, or poorly governed data inherit those problems and often amplify them. The institutions seeing real production value from AI are, almost without exception, the ones that had already invested in data architecture discipline before the AI initiative began. 

Regulatory acceptance. DORA's operational resilience requirements and existing EBA model risk guidance don't prohibit AI adoption, but they do require that any AI system supporting a critical function be governed with the same rigor as any other critical IT system — documented, tested, monitored, and subject to clear accountability. Treating AI as exempt from this because it's "new" is the fastest way to end up under regulatory scrutiny. 

Banks that are moving deliberately on AI adoption — piloting narrowly, scaling what works, and holding a hard line on explainability before deploying anything customer- or decision-facing — are not behind. They're making a defensible risk decision in an environment where the cost of an ungoverned AI failure is measured in regulatory findings, not just bad press. 

The institutions worth watching aren't the ones with the flashiest AI announcement. They're the ones whose production AI systems — in fraud, document processing, and support triage — have been running quietly and reliably for a year or more, while the more ambitious use cases stay in carefully bounded pilots until the explainability and governance questions have real answers.

AI in Banking Operations 

AI in banking: where fraud detection and document processing deliver real ROI, and where autonomous decisioning still falls short of regulatory reality

What Works in Production and What Is Still Hype 

Modernizing a core banking system is not a technology decision. It is a risk decision — and the business case for it must be built on the same terms leadership uses to evaluate any other material risk: quantified cost, structured mitigation, and a credible delivery path. For engineering leaders, that means translating what you see daily in the codebase into language that moves a budget committee. 

The most powerful argument for modernization is not the future state. It is the present one, rendered in numbers. 

Outage costs are the clearest entry point. A major European bank's core system downtime costs an average of €1.7 million per hour when you account for transaction failure, support escalation, regulatory notification obligations under DORA Article 19, and reputational exposure. If your institution has had two or three significant incidents in the past eighteen months, that figure is not hypothetical — it is already in your incident logs. 

Developer velocity is the second cost that rarely appears on a balance sheet but is felt everywhere. In legacy Angular 8 or AngularJS frontends still consuming REST adapters over a SOAP core, a simple feature addition — say, adding a new payment rail — can require touching twelve separate modules, regenerating stubs, and manually coordinating state across components that were never designed to share it. Track this in your next sprint: count the hours spent on integration scaffolding versus product logic. The ratio is your argument. 

Compliance drift is the third line item. DORA, NIS2, and EBA ICT guidelines require auditability, resilience testing, and documented change management. Legacy systems often cannot produce the artefacts these frameworks demand without manual intervention — which is itself a control gap. Price that gap as the cost of the remediation work your team performs before every audit. 

Define the Investment Envelope Before You Propose a Number 

Before you can defend a modernization budget, you need a credible cost structure. That means breaking the investment into three components: 

Migration cost covers the replatforming of core services — account management, payment processing, ledger — typically to a microservices architecture backed by Kafka for event streaming and Flink for real-time processing. For the frontend, this is the moment to move from a fragmented Angular module federation into a properly structured standalone component architecture using Angular 17+ with signals-based reactivity. The cost here is measurable: team size, timeline, and tooling. 

Parallel operation cost covers the period during which old and new systems run simultaneously. This is unavoidable for a regulated institution. Budget for it explicitly: infrastructure duplication, dual maintenance, and the integration layer — typically an anti-corruption layer (ACL) pattern — that lets the new Angular frontend consume new API contracts while the legacy core remains authoritative for a subset of domains. 

Opportunity cost deferral is the cost of what you will not build during the migration window. Be honest about this in the business case. A migration that consumes your entire senior Angular team for eight months means eight months of deferred feature delivery. Frame it as a one-time deferral against a permanent reduction in carrying cost. 

Phase the Migration to Make the Risk Legible 

No board will approve a three-year big-bang rewrite. Structure the migration in phases, each with a defined exit criterion and a rollback position. 

Strangler Fig at the API boundary. Introduce a BFF (Backend for Frontend) layer — ideally a Node or Spring-based gateway — that intercepts calls from your Angular frontend and routes them selectively to new microservices as they come online. The Angular application itself changes minimally in this phase; what changes is what it talks to. This phase produces measurable outcomes: latency reduction, error rate improvement, and the first DORA-compliant audit trail on the new stack. 

Frontend decomposition. Migrate Angular modules to standalone components, introduce NgRx Signal Store or a lightweight signals-based state pattern to replace legacy service-based state sharing, and establish an Observable data layer using RxJS pipelines that map cleanly to the new event-driven backend. Each component migration is independently testable and independently deployable. This phase reduces the regression surface with each release. 

Core cutover by domain. Move ledger, payments, and customer data to the new core in sequence, not simultaneously. Each domain cutover is preceded by a shadow-mode period — the new service processes transactions in parallel with the legacy system, with output compared but not applied. Discrepancies surface before they become incidents. 

This structure gives leadership a phased risk profile: each phase has a defined cost, a defined outcome, and a defined point at which you can stop if the risk calculus changes. 

The internal team cannot carry a core modernization alone. The business case must account for external delivery capacity — and the selection of that partner is itself a risk decision. 

The criteria that matter in this context are narrow: demonstrated delivery on Angular modernization in regulated environments, familiarity with event-driven architectures (Kafka, Flink), and a working understanding of the compliance constraints that govern what you can and cannot deploy. A partner who has never operated under DORA change management gates will discover those constraints mid-sprint, not in the proposal. That discovery has a cost. 

Require specific examples. Ask how they have handled the strangler fig pattern in production, how they manage Angular version migration on legacy codebases, and how their team interfaces with your compliance function. A credible partner will have concrete answers. A vendor who cannot cite a real modernization engagement at this level of specificity is a risk your business case should not absorb. 

The business case for core banking modernization closes on one argument: the cost of the status quo is not static. Every quarter you operate on a legacy core, the remediation cost increases, the compliance exposure widens, and the gap between your developer velocity and your competitors' grows. The investment required to modernize is significant. The cost of not doing so is compounding. 

That is the frame. Build the numbers around it. 

OceanoBe works with European banks and financial institutions navigating core modernization — from business case development to phased delivery on regulated stacks. If your team is building the internal case, we are happy to work through the architecture and cost structure with you. 

How to Build a Business Case for Core Banking Modernization

How engineering leaders quantify the true cost of legacy banking systems and build a phased modernization business case that moves a budget committee. 

Start With the Cost of Doing Nothing 

Fraud detection in banking is a data problem before it is a model problem. The features fed into a classifier, the hypotheses that guide anomaly investigation, and the explanations surfaced to compliance teams all depend on someone asking the right questions of the right data — quickly enough to matter. For data engineers and ML engineers working on fraud systems, prompt engineering with Claude has become a practical accelerator across three specific workflows: feature engineering, anomaly detection hypothesis generation, and model explainability. 

This article covers each workflow with concrete prompt patterns you can adapt directly to your environment. 

Feature selection is where fraud models are won or lost. A classifier trained on the wrong features will produce confident, wrong predictions — and in a high-stakes environment, confident and wrong is worse than uncertain. The challenge is that feature ideation is time-consuming: it requires domain knowledge, familiarity with transaction patterns, and the ability to reason about how fraudsters adapt to existing controls. 

Claude accelerates this process by acting as a structured thinking partner. The prompt pattern is straightforward: provide the transaction schema, describe the fraud typology you are targeting, and ask for candidate features with explicit reasoning for each. 

You are a fraud detection engineer working on a card-not-present fraud model for a European retail bank. The transaction schema includes: merchant_category_code, transaction_amount, timestamp, device_fingerprint, ip_geolocation, time_since_last_transaction, and customer_tenure_days. 

Generate 10 candidate features for detecting account takeover fraud. For each feature, explain the fraud signal it encodes and any data quality risks that would make it unreliable in production.  

The instruction to include data quality risks is important. It forces the output to be operationally useful rather than theoretically complete — a distinction that matters when you are deciding what to build versus what to document as a future consideration. 

Important: Before sending any schema or transaction data to Claude, ensure all fields are anonymised or synthetic. No real customer identifiers, account numbers, or PII should appear in prompts. This is a non-negotiable requirement under GDPR, regardless of how the LLM processes or retains input data. 

Anomaly detection models surface outliers — but outliers require interpretation. A transaction flagged as anomalous is not inherently fraudulent; it may reflect a legitimate behavioural change, a data pipeline error, or a genuine fraud pattern. The investigative bottleneck is generating plausible hypotheses fast enough to prioritise the queue. 

Claude is effective here when given a specific anomaly description and asked to generate competing explanations ranked by likelihood. The prompt structure should constrain the output to the relevant fraud typologies for your institution and explicitly request that benign explanations be included alongside malicious ones — otherwise the output skews toward false positives. 

A customer with 8 years of tenure and a stable transaction history made 4 international transfers to new beneficiaries within 90 minutes, totalling €14,000. The transactions originated from a device not previously associated with the account. The customer has not contacted support. 

Generate 5 hypotheses to explain this pattern, ranked by likelihood. Include at least one benign explanation. For each hypothesis, identify the additional data points that would confirm or rule it out. 

This pattern is useful for building investigation playbooks as well as for real-time triage. The output should be treated as a starting point for analyst review — not a decision. LLMs can produce plausible-sounding but incorrect reasoning, and in a fraud context, an AI-generated hypothesis that goes unverified before action is a liability, not an asset. 

Regulators and internal audit functions increasingly expect fraud model decisions to be explainable in plain language. This applies particularly to adverse decisions — declined transactions, blocked accounts, SAR filings — where the institution must be able to articulate why the model flagged a case. ML engineers are often responsible for producing these explanations, which creates a translation problem: SHAP values and feature importances are technically correct but not audit-ready. 

Claude can convert model output into structured, human-readable explanations when given the right input. 

A fraud detection model assigned a risk score of 0.91 to a transaction. The top contributing SHAP features were: ip_geolocation_mismatch (+0.34), time_since_last_transaction_seconds (+0.28), new_device (+0.19), transaction_amount_vs_30d_average (+0.11). 

Write a plain-language explanation of why this transaction was flagged, suitable for inclusion in an internal audit log. The explanation should reference only the features provided, make no causal claims beyond what the feature values support, and avoid probabilistic language that implies certainty. 

Two requirements in that prompt are doing critical work. First, restricting the explanation to provided features prevents Claude from fabricating plausible-sounding but unsupported reasoning — a real risk when LLMs are asked to explain decisions with incomplete context. Second, prohibiting certainty language keeps the output defensible: audit logs that overstate model confidence create compliance exposure. 

Any Claude-generated explanation going into an audit log or regulatory submission must be reviewed by a qualified analyst before it is recorded. LLM output in this context is a drafting aid, not a final artefact. 

A note on prompt injection: In automated pipelines where transaction data is passed directly into prompts, there is a risk that adversarially crafted input — data fields containing instruction-like text — could alter model behaviour. Sanitise and validate all data fields before they enter a prompt template. Treat LLM inputs in automated fraud pipelines with the same discipline applied to any external input in a production system. 

Two frameworks are directly relevant to this work. The EU AI Act's Annex III classifies certain AI systems used in financial services as high-risk, with credit scoring explicitly named. Fraud detection sits in a more nuanced position: depending on implementation and the decisions it informs, it may attract similar obligations around transparency, human oversight, and documentation — but institutions should obtain a specific legal assessment rather than assuming it falls under the same classification as credit scoring. 

On explainability specifically: the applicable accountability standards come from EBA guidelines on internal governance (GL/2021/05) and, where internal models inform risk decisions, the ECB Guide to Internal Models. These set expectations for how model-driven decisions are documented and challenged — not DORA, which governs ICT risk and operational resilience, not ML explainability. 

The prompt patterns here are starting points, not production templates. Effective use of Claude in a fraud engineering context requires establishing institution-specific prompt libraries, testing outputs against known fraud cases, and defining clear human review gates — particularly for anything that touches audit logs or regulatory reporting. The engineers who get the most from this tooling are those who treat Claude as a structured reasoning accelerator, not an autonomous decision-maker. 

Prompt Engineering for Fraud Detection Models 

Data and ML engineers use Claude to accelerate fraud detection pipelines — pattern exploration, feature engineering, and explainability

AI Prompting for Real Banking Systems 

The database layer is one of the least visible components in a financial system — and one of the most consequential. When it is configured correctly, transactions settle reliably, audit trails are complete, and the system scales without incident. When it is not, the failure modes are severe: duplicate transactions, inconsistent balances, compliance gaps, and outages that regulators treat as operational risk events under DORA. 

For senior decision-makers evaluating technology strategy or vendor capability, understanding the basic taxonomy of database choices — and where each is appropriate — is not a technical luxury. It is a governance requirement. 

The Non-Negotiable Baseline: ACID Compliance 

Before any architectural decision, one requirement must be fixed: financial data must be managed by a storage layer that guarantees ACID properties — Atomicity, Consistency, Isolation, and Durability. In plain terms, this means that a payment either completes fully or does not complete at all; that two transactions cannot corrupt each other's data by running simultaneously; and that once a transaction is confirmed, it cannot be silently lost. 

ACID compliance is not a differentiating feature. It is the floor. Any database used for ledger data, payment records, or customer account balances must meet this standard without exception. The architectures that follow differ in how they meet it — and at what scale. 

PostgreSQL remains the most widely deployed database in European fintech and banking environments, and for sound reasons. It provides full ACID compliance, mature tooling, deep support for regulatory audit patterns, and a strong operational track record in regulated industries. For institutions with transaction volumes that do not require geographic distribution — which covers the majority of mid-sized banks and payment processors — PostgreSQL is the correct default. 

Its constraints are structural rather than technical. A single PostgreSQL instance, even when optimised, has ceiling limits on write throughput. Replication strategies can extend read capacity, but they introduce complexity and do not eliminate the fundamental single-node write bottleneck. For institutions whose transaction volumes are growing toward that ceiling, or who need active-active deployments across multiple regions to meet availability requirements, PostgreSQL alone is no longer sufficient. 

The question is not whether PostgreSQL is reliable — it is — but whether the operational model it requires fits the scale and availability profile of the institution. 

Distributed SQL: CockroachDB and YugabyteDB 

Distributed SQL databases were designed to solve the specific problem PostgreSQL cannot: horizontal scale without sacrificing ACID guarantees. Both CockroachDB and YugabyteDB provide strongly consistent, distributed storage — meaning that transactions behave correctly across multiple nodes and, in multi-region deployments, across geographically distributed data centres. 

This matters in two scenarios that are increasingly common in European financial services. The first is volume: payment platforms handling tens of millions of transactions per day will eventually exhaust what a single-node architecture can support. The second is geography: PSD3 and national data residency regulations are pushing institutions toward multi-region deployments, and distributed SQL is engineered for precisely this operating model. 

CockroachDB and YugabyteDB are architecturally comparable at the level of guarantees they provide. The practical differentiators — licensing models, support structures, operational maturity, and compatibility with existing PostgreSQL tooling — are the factors that determine which is appropriate for a given institution. Both are PostgreSQL-wire-compatible, meaning that the migration path from a PostgreSQL environment is less disruptive than switching to a fundamentally different paradigm. 

The cost of distributed SQL is operational complexity. These systems require engineering teams with the knowledge to configure, monitor, and operate them correctly. When evaluating a software development partner's capability in this area, the right question is not whether they have used these databases, but whether they can demonstrate production deployments in regulated environments — including how they handle schema migrations, node failures, and multi-region failover under compliance constraints. 

NoSQL: Where It Belongs in a Financial Architecture 

NoSQL databases — document stores, key-value stores, time-series engines — are appropriate in financial architectures, but only in specific, bounded contexts. The critical discipline is ensuring they are never placed in the path of data that requires transactional integrity. 

Appropriate use cases include session management, rate-limiting state, fraud signal caching, audit log ingestion at high throughput, and read-optimised reporting pipelines where eventual consistency is acceptable. In a well-designed fintech architecture, a system might use Redis for real-time fraud signal lookups, Kafka-backed storage for event stream processing, and a NoSQL document store for flexible product configuration data — all feeding a PostgreSQL or distributed SQL core that holds the actual ledger. 

The architectural risk is boundary creep. NoSQL databases are performant and developer-friendly, which creates pressure to extend their use beyond the bounded contexts for which they are suitable. Institutions should expect their development partner to define and enforce these boundaries explicitly, and to document the data flow between components with sufficient clarity that an internal audit function or external regulator can trace the path of any transaction from initiation to settlement. 

Three questions determine the appropriate architecture for any financial system: 

What is the write volume, and is it expected to grow beyond what a single node can sustain? 

If yes, distributed SQL belongs in the evaluation. If current and projected volumes are comfortably within single-node limits, PostgreSQL offers lower operational complexity at equivalent consistency guarantees. 

What are the geographic distribution and residency requirements? 

Multi-region active-active availability — increasingly expected under DORA's operational resilience requirements — is a strong signal for distributed SQL. 

What data is genuinely non-transactional? 

The answer to this question defines the boundary of appropriate NoSQL use. Everything outside that boundary should be treated as transactional by default. 

The institutions that make this decision well are those whose development partners raise it before implementation begins — not after the ledger is already sitting on a document store. 

Database Architecture for Financial Applications 

ACID compliance is the floor — not a differentiator. Here is how to choose between PostgreSQL, CockroachDB, YugabyteDB, and NoSQL for financial systems

Choosing Between ACID, Distributed SQL, and NoSQL 

PSD2 opened the door. PSD3 is widening it — and changing the frame entirely. 

While the final legislative timeline for PSD3 continues to evolve through the European Parliament, the direction of travel is clear enough to act on. Banks that wait for full regulatory certainty before assessing their infrastructure readiness will find themselves compressing difficult technical decisions into short implementation windows. The institutions positioning well now are not guessing at outcomes — they are making deliberate choices about what to build, what to defer, and what to evaluate before the obligation arrives. 

This article is for the leaders making those choices: not the engineers who will implement them, but the COOs, managing directors, heads of compliance, and business architects who need to understand what PSD3 means for their technology strategy without needing to read the technical specifications themselves. 

PSD2 established the principle that banks must provide third-party providers access to customer account data via APIs, with customer consent. PSD3 extends that principle in three directions that carry meaningful technical consequence. 

Where PSD2 focused on payment accounts, PSD3 moves toward open finance — drawing in savings accounts, investments, loans, and insurance data within a single consent framework. The API surface a bank must expose increases significantly. 

PSD3 tightens Strong Customer Authentication rules, addressing ambiguities in PSD2 that allowed inconsistent implementation across member states. The exemption thresholds are narrowing, and the evidentiary requirements for dynamic linking — tying an authentication event to a specific transaction — are becoming more demanding. 

PSD3 introduces more granular consent management obligations and shifts certain liability positions in dispute scenarios, particularly around authorised push payment fraud. Banks will need to demonstrate that consent was captured, stored, and honoured in ways that are auditable on demand. 

Each of these changes has a technology implication. None of them can be addressed with a configuration change or a policy update alone. 

The Engineering Implications — In Business Terms 

For non-technical leaders, the key translation is this: PSD3 compliance is not a legal project with a technology component. It is a technology project with a legal deadline. 

API surface expansion means that systems currently serving a narrow set of approved third-party integrations will need to be re-architected to support a broader data estate at production-grade reliability and security. Banks running internal APIs that were not designed for external consumption — common in institutions that implemented PSD2 on a minimum viable basis — will face the largest gap. An API gateway layer that can enforce rate limiting, authentication, versioning, and audit logging at scale is not optional infrastructure here; it is the compliance mechanism. 

SCA strengthening requires changes to authentication flows that may touch mobile applications, web banking interfaces, and backend identity services simultaneously. The dynamic linking requirements in particular — where the authentication must cryptographically reference the specific payee and amount — need to be embedded at the transaction layer, not bolted on at the authentication layer. Institutions using FIDO2-based authentication are better positioned here; those still relying on SMS OTP face a more substantive remediation path. 

Consent and audit obligations demand that every consent grant, modification, and revocation is captured as a durable, queryable event — not simply a state change in a database. This is where streaming infrastructure matters: in a Kafka-based architecture, consent events flow as an immutable log that can be replayed, audited, and reported against without reconstructing state from transactional records. Banks without this kind of event architecture will find consent auditability expensive to retrofit. 

The regulatory timeline gives some room, but the infrastructure decisions do not have the same flexibility. Three questions are worth resolving in the near term. 

Is your API layer production-ready for open finance scope?  

Not theoretically — in practice. Can it handle the authentication, rate limiting, versioning, and monitoring requirements that a broader data scope will demand? If the honest answer is that it was built to satisfy PSD2 minimum requirements and has not been revisited, that assessment needs to happen now, not when an implementation deadline is confirmed. 

What is your SCA gap against PSD3 expectations?  

A compliance team review of current authentication flows against the draft PSD3 SCA requirements will surface whether remediation is incremental or structural. The answer significantly affects resourcing and timeline estimates. 

Do you have event-level auditability for consent?  

Pull a test case: can your team reconstruct the full consent history for a given customer, including all grants, modifications, and revocations, in response to a regulatory inquiry today? If that requires manual investigation across multiple systems, PSD3's consent obligations will require infrastructure change, not process change. 

Not every decision needs to be made before the regulation is final. UI/UX changes to consent journeys, third-party developer portal design, and detailed SLA commitments to TPPs are all areas where finalised regulatory text will provide specificity that current drafts do not. 

The deferral risk to manage is assuming that infrastructure decisions fall into the same category. They do not. An API gateway re-architecture or a Kafka-based event log implementation is a multi-quarter programme — not something that can be initiated once a transposition deadline is published. 

The practical question for business leaders is not "do we understand PSD3?" It is "do we know what our current infrastructure can and cannot do — and does our technology leadership have a clear view of the gap?" 

Banks with modern, API-first architectures and event-driven data layers are largely building on foundations that PSD3 aligns with. Banks whose core infrastructure was designed for a pre-open banking world — even if PSD2 compliance has been achieved — are likely carrying technical debt that PSD3 will make visible. 

That assessment is worth commissioning independently of the legislative timeline. 

OceanoBe works with banks and financial institutions across Europe to evaluate and implement the infrastructure changes that open banking and open finance regulation demands — from API gateway architecture to event-driven consent management built on Kafka. If you are beginning that assessment, we are a useful conversation to have early. 

Open Banking and PSD3 

PSD3 expands open banking into open finance. Here is what non-technical banking leaders need to assess and decide before the regulatory deadline arrives. 

What Non-Technical Leaders at Banks Need to Know Now 

When a payment system goes down at a European bank, the clock starts immediately. Direct transaction losses accumulate by the minute. Customer service volumes spike. Regulatory notification windows open. And reputational damage — harder to quantify but no less real — begins before the incident is even resolved. 

Industry estimates put the cost of a major payment system outage at seven figures per hour for mid-to-large institutions. For banks operating under DORA, NIS2, and EBA ICT risk guidelines, the financial exposure extends well beyond lost revenue: supervisory fines, mandatory incident reporting, and post-incident audits add layers of cost that can outlast the outage itself by months. 

Reliability, then, is not an engineering concern sitting somewhere below the line. It is a business risk that belongs in the same conversation as credit risk, liquidity risk, and compliance posture. 

What "Reliability" Actually Means in Banking 

Reliability engineering in financial systems is the practice of designing for failure before failure happens. The underlying assumption is straightforward: in distributed systems processing millions of transactions daily, components will fail. The question is whether the system has been built to absorb that failure gracefully — or whether a single point of failure brings down the whole stack. 

For banking systems, this translates into a specific set of engineering disciplines: defining measurable uptime targets, managing the tolerance for degraded performance, and testing failure scenarios in controlled conditions before they occur in production. 

Three practices sit at the centre of this approach. 

SLOs and Error Budgets: Reliability as a Contract 

A Service Level Objective (SLO) is a defined threshold for system behaviour — availability, latency, error rate — that the engineering team commits to maintaining. For a payment processing service, an SLO might specify 99.95% availability over a rolling 30-day window. That figure has a direct operational translation: no more than approximately 22 minutes of downtime per month. 

The error budget is what remains when availability falls short of the SLO ceiling. If the SLO is 99.95% and the system achieves 99.92%, the error budget has been partially consumed. Engineering teams use this budget as a decision-making instrument: when the budget is healthy, deployment velocity can be higher and experimentation is appropriate; when the budget is running low, stability work takes precedence over new feature releases. 

For banking leadership, SLOs reframe a technical metric into a business conversation. A VP of Operations asking "how resilient is the payment system?" gets a more useful answer from an error budget report than from a generic uptime dashboard. It also creates accountability — teams that consistently exhaust error budgets are surfacing a structural problem, not a run of bad luck. 

Circuit Breakers: Containing Failure Before It Cascades 

In a payment processing pipeline built on Apache Kafka and Apache Flink, a single degraded downstream service — a fraud scoring engine, a core banking integration, a notification service — can propagate latency and errors upstream if the system has no mechanism to isolate the failure. 

Circuit breakers address this directly. When a downstream dependency begins returning errors above a defined threshold, the circuit breaker opens: calls to that dependency are halted, a fallback behaviour is triggered, and the rest of the pipeline continues processing. After a defined interval, the circuit moves to a half-open state and tests whether the dependency has recovered before resuming normal traffic. 

The business outcome is containment. Rather than a single failing integration degrading the entire payment flow, the failure is isolated, the customer-facing impact is bounded, and the operations team receives a clean signal about which component requires attention. In practical terms, this is the difference between a P1 incident affecting all payment channels and a degraded-mode event affecting one integration point. 

Chaos Engineering: Testing Failure on Your Terms 

The premise of chaos engineering is that the worst time to discover how a system fails is during a live incident. Chaos engineering inverts this by deliberately injecting failure — terminated instances, introduced latency, severed network paths — in controlled conditions, with observability in place and a recovery plan ready. 

Tools like Chaos Monkey and Gremlin are commonly used to run these experiments against production-grade environments. In a Kafka and Flink-based streaming architecture, a chaos experiment might involve killing a Flink task manager mid-processing to observe whether state recovery behaves as expected, or simulating a Kafka broker failure to validate that consumer groups rebalance within acceptable latency bounds. 

For regulated institutions, chaos engineering also has a compliance dimension. DORA's ICT resilience requirements expect banks to demonstrate that digital operational resilience has been tested — not assumed. A documented chaos engineering programme, with defined hypotheses, controlled blast radius, and recorded outcomes, provides exactly the kind of evidence that satisfies both internal risk committees and supervisory expectations. 

Connecting Engineering Practice to Business Outcomes 

The practices described here are not independent technical disciplines. They form a coherent reliability framework with direct business implications. 

SLOs define what reliability means for a given service and hold teams accountable to it. Error budgets translate that definition into a deployment and prioritisation policy. Circuit breakers limit the blast radius of component failures, protecting customer experience during partial outages. Chaos engineering builds confidence that the system will behave as designed when real failure occurs — and satisfies the regulatory expectation that resilience has been actively validated, not merely assumed. 

For COOs, CROs, and managing directors evaluating the maturity of their technology estate, the question is not whether these practices sound sophisticated. The question is whether the bank's current payment infrastructure could absorb a Flink task failure, a Kafka broker outage, or a degraded third-party integration without triggering a seven-figure incident. 

If the honest answer is uncertain, that uncertainty is itself the risk to manage. 

Building Reliability That Regulators and Customers Can Depend On 

Reliability engineering is increasingly part of the regulatory baseline for European banks, not a differentiator. DORA's ICT risk and resilience requirements, EBA guidelines on operational continuity, and NIS2 obligations around incident response all point in the same direction: institutions are expected to demonstrate tested, documented resilience — not to assert it. 

OceanoBe works with banks and financial institutions to design and implement payment and banking systems built to these standards — from streaming pipeline architecture on Kafka and Flink to reliability practices that satisfy both engineering rigour and supervisory scrutiny. 

The Cost of a Banking Outage 

Payment system outages cost European banks seven figures per hour. See how SLOs, error budgets, circuit breakers, and chaos engineering reduce that risk

Engineering Reliability Into Financial Systems 

Banking systems carry a structural tension: the write side of a transaction demands strong consistency — a debit and credit must be atomic, ledger balances must never diverge — while the read side, used for statements, dashboards, fraud monitoring, and regulatory reporting, needs to scale independently and serve queries that have nothing to do with how the data was written. CQRS and event sourcing exist to resolve exactly this tension. Used well, they produce systems that are both transactionally sound and operationally scalable. Used without discipline, they produce distributed complexity that the team didn't need to take on. 

CQRS separates the write model from the read model. The write side accepts commands — debit account, settle transaction — and enforces invariants synchronously: balance checks, fraud holds, regulatory limits. The read side serves queries from one or more denormalized projections, built independently of the write model's schema and scaled to match query load rather than transaction load. 

Event sourcing complements this by making the write model an append-only log of events rather than a mutable current-state table. Instead of storing "account balance: €4,200," the system stores every event that produced that balance — FundsDeposited, FundsWithdrawn, HoldPlaced — and derives current state by replaying them. The audit trail isn't a separate logging concern bolted on afterward; it's the data model itself, which is precisely the property that makes this pattern attractive under DORA and PSD2 reporting obligations, where institutions must reconstruct the full history of a transaction's state, not just its final value. 

Implementing Projections with Kafka and Flink 

In practice, the write side publishes domain events to a Kafka topic immediately after they're committed to the event store. Flink jobs consume that stream and build one or more read-optimized projections — an account-balance view, a daily-statement view, a fraud-scoring view — each shaped for its specific query pattern rather than forced into a single shared schema. 

// Flink job sketch: building an account balance projection 

  .process(new KeyedProcessFunction<>() { 

      void processElement(AccountEvent event, Context ctx, Collector<BalanceView> out) { 

          BigDecimal current = balance.value(); 

          BigDecimal updated = applyEvent(current, event); 

          out.collect(new BalanceView(event.accountId, updated, event.timestamp)); 

Each projection is disposable. If the projection logic is wrong, or a new read pattern emerges, the projection is dropped and rebuilt from the event log rather than migrated in place — a meaningful operational advantage over schema migrations on a live transactional table. 

Projection rebuilds are routine in a mature CQRS implementation, not an exceptional event. A common approach: stand up the new projection version alongside the old one, replay the full event history from Kafka's compacted topic (or a cold-storage event archive for older history), and cut traffic over once the new projection has caught up to the live stream. 

flinkJob.fromSavepoint(null)        // start with empty state 

        .consume(eventTopic, fromOffset = EARLIEST) 

// cut over reads to newProjectionStore once lag == 0 

This blue-green replay pattern avoids downtime and gives teams a clean rollback path: if the new projection has a defect, traffic simply routes back to the prior version while the event log — the actual source of truth — remains untouched. 

Handling Eventual Consistency in User-Facing Flows 

The hard part is rarely the architecture; it's the user experience implication. A customer who submits a transfer and immediately checks their balance may hit a projection that hasn't caught up yet. For most reporting and analytics use cases, seconds of lag is irrelevant. For balance display immediately after a write, it isn't. 

Teams handle this with a few established patterns: read-your-own-writes by serving the post-command response from the command-side state rather than waiting on the projection, optimistic UI updates that reflect the expected post-transaction state immediately, or a short synchronous wait with a fallback to "processing" status if the projection lag exceeds a threshold. The choice depends on which flows are consistency-sensitive — balance checks and transaction confirmations usually are; historical statements and dashboards usually aren't. 

Where It Adds Value vs Where It Over-Complicates 

CQRS and event sourcing earn their complexity where audit requirements are non-negotiable, where read and write loads genuinely diverge in scale, and where multiple, differently-shaped views of the same data are a permanent business requirement — core ledgers, payment processing, transaction monitoring. These are domains where the operational cost of running an event log, projection infrastructure, and rebuild tooling is paid back in regulatory defensibility and scalability. 

It over-complicates domains that don't have this profile: internal admin tools, low-volume configuration data, services where a single well-indexed relational table already serves every read pattern the business needs. The pattern is frequently adopted because it's architecturally interesting, not because the system's actual consistency and scale requirements call for it — and the resulting maintenance burden falls on whichever team inherits the system next. 

The right call depends less on the pattern's theoretical merits and more on a clear-eyed read of where a specific institution's read and write paths actually diverge — and where they don't. 

CQRS and Event Sourcing in Banking 

CQRS and event sourcing in banking: implementing projections, rebuilding read models, and managing eventual consistency — without over-engineering core systems.

When to Use Them and How to Implement Correctly 

Test coverage in core banking environments has a structural problem: the systems most in need of rigorous testing are often the ones with the least documented behavior. Decades-old COBOL and PL/I modules encode business rules that were never written down elsewhere — interest accrual edge cases, batch cutoff logic, currency rounding conventions inherited from pre-euro systems. Writing meaningful tests against this kind of system requires first reconstructing what "correct" actually means. This is where AI-assisted prompting earns its place in the QA workflow — not as a shortcut to more tests, but as a method for surfacing the scenarios a team didn't know to test for. 

Prompting for Test Generation, Not Test Volume 

The naive use of AI in test automation is asking a model to "write unit tests for this function." Against a legacy core banking module, this produces tests that mirror the code's existing logic — useful for regression safety, but blind to the cases where the logic itself is wrong or incomplete. Engineering teams get more value from prompts that separate two distinct tasks: understanding behavior, then testing behavior. 

Example prompt (GitHub Copilot, inline during development): 

"Trace this COBOL paragraph and list every branch condition, numeric threshold, and date comparison it evaluates. For each one, state the business rule it appears to implement. Do not generate tests yet." 

This first pass surfaces the implicit rule set before any test code is written. Claude is better suited to the second stage, where reasoning needs to span an entire transaction flow rather than a single paragraph or function: 

 "Here is the full settlement batch routine across these four COBOL programs [paste/attach]. Identify any business rule applied inconsistently between them — for example, a rounding method used in one program but not another. List discrepancies before suggesting tests." 

Only once these discrepancies and rules are confirmed by an engineer does it make sense to ask for test generation against them. 

Legacy core banking systems accumulate edge cases the way old buildings accumulate plumbing modifications — each one solving a real problem at the time, none of them documented for the next person. Prompting AI models to generate edge cases works best when the prompt supplies the domain constraints explicitly rather than asking generically for "edge cases." 

"Generate edge-case test scenarios for an account interest calculation routine. Constraints to cover: month-end and year-end batch boundaries, leap-year date handling, multi-currency rounding to two vs. zero decimal places, accounts mid-migration between core systems, and timing gaps between transaction authorization and settlement. For each scenario, state the expected behavior and why it's non-obvious." 

Given these constraints, AI models reliably generate scenario lists that QA engineers would otherwise assemble manually from tribal knowledge and past incident reports. The output still requires validation against actual system behavior — a model has no visibility into a specific bank's historical workarounds — but it consistently surfaces more candidate scenarios per hour than manual enumeration. 

Contract Testing Prompts at Integration Boundaries 

Where legacy cores connect to modern services — API gateways, fraud engines, customer-facing applications — contract testing matters more than end-to-end testing. The legacy side of that boundary rarely has a machine-readable schema; its "contract" is whatever behavior the mainframe has always exhibited, including its quirks. 

"Here are 20 sample request/response pairs captured from the legacy account-lookup interface [paste samples], and a description of what the consuming microservice expects from each field. Generate a Pact-style consumer contract, including field-level assertions that would catch a silent format change — for example, an account number changing length or a field changing from required to optional." 

For legacy integration work specifically, this matters more than it does in modern microservice contexts, because the legacy side often cannot be modified to fail loudly when its contract changes — a downstream consumer may be the first to notice a break in production. 

Property-based testing — generating large volumes of varied input to verify that certain invariants always hold, rather than checking fixed examples — is well suited to financial logic, where properties like "debits and credits across a transaction always net to zero" are easier to state than exhaustive example sets. The challenge has always been articulating the properties in the first place, particularly for legacy modules where the rules are implicit. 

AI Prompting for Test Automation in Banking Systems 

AI prompting helps banking QA teams test legacy core systems, generating edge cases, contract tests, and property-based tests across critical system boundaries

All News

Categories

All News

Categories

Do you want to read more?

Subscribe now for our bimonthly newsletter!