As a frontend developer who's spent the last few years inside a growing Angular banking platform, I've watched the same story play out more than once: a single Angular application starts clean, grows a module for every product line — accounts, cards, lending, payments — and within eighteen months, a change to the lending module requires a full rebuild and regression pass of the entire app before anyone can ship it. The team hasn't grown incompetent. The architecture has grown a coordination tax that scales with headcount, not with the size of any individual change. 

Module Federation is the answer most teams reach for once this tax becomes visible. It's worth being precise about what it actually solves, because it isn't a frontend performance optimisation — it's a release-governance change, and in a banking context, release governance is not a decision frontend teams get to make unilaterally. 

At a technical level, Module Federation lets independently built and deployed Angular applications — remotes — expose modules that a host application loads at runtime, rather than at build time. The lending team can ship a new version of the lending micro-frontend on its own schedule, and the host shell picks it up on next page load, with no rebuild of the accounts or payments modules required. 

The appeal for a team lead is obvious: the lending team stops being blocked on the payments team's release cadence, and vice versa. Each team owns its deployment pipeline, its own dependency versions where feasible, and its own release timing. For a bank running multiple product squads against one platform, this is often the difference between shipping weekly and shipping quarterly. 

Where It Gets Harder Than the Tutorials Suggest 

Every Module Federation walkthrough demonstrates two remotes and a host in isolation. Production banking platforms surface three problems that tutorial-scale examples don't: 

Angular, RxJS, and any shared design-system library need to be either strictly aligned across remotes or explicitly declared as independently versioned with fallback resolution. Get this wrong and you either duplicate a large shared dependency across every remote — inflating load time for exactly the customer-facing experience you were trying to improve — or you get a runtime version mismatch that surfaces as a defect only in the specific combination of remotes a customer happens to load together. This second failure mode is genuinely difficult to reproduce in an isolated test environment, because it only manifests when specific remote versions are combined at runtime. 

The interface a remote exposes to the host — the modules, the shared state contracts, the routing hooks — is now a versioned API between teams, whether or not anyone formally treats it as one. A lending team shipping a breaking change to what it exposes, without a deprecation path, produces a runtime failure in the host shell that no build-time type check will catch, because the host and remote are no longer compiled together. 

Regulatory traceability across independently deployed pieces

This is the one that tutorials never mention and banking platforms can't ignore. If the lending micro-frontend and the payments micro-frontend are deployed independently, an auditor asking "what version of the platform was live for this customer on this date" needs an answer that spans every remote in the combination the customer actually loaded — not just the host shell's version number. 

This is the crux of it: Module Federation trades build-time coupling for runtime composition risk. That trade is worth making — the team velocity gain is real — but it only holds up if the governance layer is built alongside the technical migration, not after. 

In practice this means a runtime compatibility matrix that's actively maintained and enforced, not just documented: which remote versions are certified compatible with which host and sibling-remote versions, checked automatically before a new remote version is allowed to go live in production. It also means every remote's deployed version, at any point in time, needs to be logged with enough fidelity that "what was live for this customer on this date" is a query against a log, not an investigation across five teams' deployment histories. 

Splitting the App Without Splitting the Team 

The framing that's helped most on our platform is that Module Federation doesn't remove the need for cross-team coordination — it relocates it. Instead of coordinating on a shared build and release train, teams coordinate on a shared contract and a shared compatibility matrix. That's a better trade for velocity, but it's still coordination, and it still needs an owner. Teams that skip this step get the deployment independence and discover the coordination gap only when a version mismatch reaches a customer, or an audit request reaches a wall of independently versioned deployment logs with no unified view across them. 

Done well, Module Federation lets a lending team ship a fix on Tuesday without waiting on payments, while a compliance function can still answer, with confidence, exactly what a given customer saw and when. Done as a pure technical migration without the governance layer, it trades a build bottleneck for an audit liability — a worse position than the monolith it replaced. 

Module Federation for Banking Platforms

Module Federation lets banking teams ship Angular micro-frontends independently, and the release-governance work that migration requires. 

Splitting a Monolithic Angular App Without Splitting the Team 

As a senior tester on banking systems, I've sat in more than one incident review where the root cause traced back to a test environment that didn't behave like production — not because the code was wrong, but because the data was. A masking script that flattened every account balance to round numbers. A synthetic customer set with no realistic distribution of edge cases: no near-threshold KYC flags, no accounts sitting right at a fraud-rule boundary, no genuinely messy legacy records. The tests passed. The behaviour they validated wasn't the behaviour production would actually see. 

Test data management in banking is not a data privacy checkbox sitting next to your GDPR compliance program. It is a testing discipline in its own right, and treating it as an afterthought to masking production exports is how realistic-looking test failures make it past QA and into a regulator's incident report instead. 

The default approach at most institutions starts with taking a production extract and masking it — replacing names, obfuscating account numbers, tokenising national ID fields. This solves the immediate compliance problem: no real PII sits in a lower environment. It does not solve the testing problem, and it introduces a few of its own. 

Masked production data still requires production access to generate in the first place, which means every refresh cycle re-opens the exact PII exposure surface you're trying to close. It also degrades in usefulness the moment masking breaks referential consistency — a masked customer ID that no longer matches across the core banking system, the fraud engine, and the CRM produces integration test failures that have nothing to do with the code under test. And critically, masked data is a snapshot. It reflects last quarter's customer distribution, not the edge cases your next release actually needs to be tested against. 

Synthetic data generation solves a different problem than masking does, and the two are complementary, not interchangeable. Masking is appropriate when you need data that mirrors a specific production state for regression or migration testing. Synthetic generation is appropriate — and usually preferable — when you need data engineered to exercise specific behaviours, at volume, without a production dependency at all. 

There's also a coverage gap that masking can't fix by definition: masked data can only ever contain the edge cases that happened to occur in the production window you extracted from. If your fraud rules changed last month to catch a new pattern, no amount of masking a six-month-old production snapshot will produce a test record that exercises the new rule. Testers relying solely on masked data end up writing manual test fixtures to patch the gap anyway — at which point the question is why the whole dataset isn't being generated with that same intentionality from the start. 

Building Statistically Realistic Synthetic Datasets 

The bar for synthetic test data in banking is higher than "looks plausible." It needs to preserve the statistical properties that make production behaviour reproducible: the actual distribution of transaction amounts, the correlation between customer segment and product holding, the realistic frequency of the edge cases that trigger your fraud, AML, and credit risk logic. Uniform random generation fails this bar immediately — real transaction data is heavy-tailed, real customer portfolios are correlated across fields, and a generator that ignores those properties will pass tests that production will fail. 

In practice, this means building generation logic off statistical profiles extracted from production — distributions, correlations, and boundary frequencies — rather than off the raw records themselves. This is a meaningful distinction from a compliance standpoint: a statistical profile (mean transaction size by segment, correlation between account age and product count, frequency of near-threshold flags) contains no individual customer information, while still faithfully reproducing the shape of the data that testing depends on. 

We've had good results using Claude, prompted against these extracted profiles, to generate the synthetic record sets themselves — writing generation scripts with GitHub Copilot assisting on the boilerplate, and using Claude to reason through edge-case coverage: given a fraud rule set, which record shapes are needed to exercise every branch, including near-miss cases that sit just inside and just outside a threshold. This is where a senior tester's judgment still matters most — a model can generate volume and can be prompted toward specific edge cases, but knowing which edge cases actually matter for a given rule engine, and which correlations in the data are load-bearing for a given test suite, is domain expertise that has to be applied to the prompt, not delegated away from it. 

A banking test environment is rarely one system. A synthetic customer needs a consistent identity across core banking, the payments engine, the fraud detection layer, and any downstream reporting or reconciliation pipeline — the same reconciliation and event-driven patterns we've covered elsewhere in this series apply directly here, since a test dataset that breaks referential consistency between a Kafka event stream and its downstream consumer produces failures indistinguishable from a genuine integration bug. 

This is usually the point where synthetic data generation projects underdeliver: the generator produces excellent individual records but no mechanism to propagate a consistent synthetic identity and its associated state across every system under test. The fix is architectural rather than a generation-technique problem — a synthetic data service that owns identity generation centrally and is queried by every downstream test data need, rather than each team generating its own synthetic dataset independently and hoping the IDs happen to line up. 

In practice, that means the synthetic identity service is the source of truth for a given test customer's state — account status, KYC flag, product holdings — and every consuming system (core banking, the fraud engine, the CRM, any reconciliation job reading off a Kafka topic) reads that state rather than maintaining its own copy. When a test scenario needs a customer whose KYC status changes mid-scenario, that transition is written once, upstream, and every downstream consumer observes the same consistent version of events. Without this, teams end up debugging phantom failures where two systems under test simply disagree about which state a shared test customer is in — a failure mode that has nothing to do with the feature being tested and everything to do with how the test data was assembled. 

Under GDPR, the presence or absence of PII in a dataset isn't the only relevant question — re-identification risk from combinations of quasi-identifiers (birth date, postcode, employer, product mix) can reconstruct an individual even from data with no direct identifiers present. A synthetic dataset built from real statistical profiles needs to be evaluated for this risk explicitly, not assumed safe because no name or account number appears in it. Differential privacy techniques applied at the profile-extraction stage — adding calibrated noise before the statistical profile is derived, rather than after synthetic records are generated — are the more defensible approach for institutions that need to document this for an auditor or under DORA's operational resilience testing requirements, which extend to how test environments themselves are managed. 

A mature test data management approach in banking treats synthetic generation as infrastructure, not a per-project script: a maintained, centrally owned service that produces statistically realistic, referentially consistent, re-identification-risk-assessed datasets on demand, engineered from the start to cover the edge cases your specific rule engines and regulatory obligations require — not retrofitted after a masking approach has already shown its limits in a failed audit or a missed edge case in production. 

Getting this right from the outset, rather than discovering the gaps through an incident review, is the difference between a testing function that gives your institution genuine confidence in a release and one that gives false confidence dressed up as a green test suite. 

Test Data Management in Banking 

Senior tester's guide to synthetic data generation and masking in banking: realistic, compliant test datasets without production PII exposure.

Generating Realistic, Compliant Datasets Without Touching Production PII 

Deploying a large language model in a customer-facing banking channel is not a prompting problem. It is a systems design problem that happens to include a prompt. Teams that treat guardrails as a matter of instruction wording — "don't discuss competitor products," "always recommend speaking to an advisor for investment questions" — are building controls that a well-crafted adversarial input, a model update, or an unusual retrieval result can quietly erode. In a regulated environment, quiet erosion is not an acceptable failure mode. 

The distinction matters because the two approaches fail differently. A prompt-level guardrail fails silently: the model still responds fluently, still sounds confident, and the output still reaches the customer. An architectural guardrail fails loudly: a request gets blocked, flagged, or routed to a human, and someone knows about it. For a bank, the second failure mode is the only acceptable one. 

System prompts and instruction tuning shape model behaviour probabilistically, not deterministically. That is fine for a marketing copy assistant. It is not fine for a channel that might be asked about account balances, dispute procedures, or — inadvertently — investment suitability. No instruction, however carefully worded, guarantees the model will never generate an out-of-scope, inaccurate, or non-compliant response to a sufficiently unusual or adversarial input. 

This is not a criticism of any particular model, including the ones we deploy for clients, such as Claude. It is a property of how instruction-following LLMs work. The engineering discipline is to accept this limitation explicitly and build the architecture around it, rather than iterating on prompt wording until failures become rare enough to stop noticing. 

Three architectural layers do the work that prompt engineering alone cannot: retrieval scoping, output validation, and escalation routing. 

Retrieval Scoping: Controlling What the Model Can See 

Most production banking chatbots are retrieval-augmented — the model does not answer from parametric memory alone, it answers based on documents or data pulled from a knowledge base at query time. Retrieval scoping is the control layer that determines what that knowledge base is allowed to contain and surface for a given user and query. 

This means enforcing entitlement boundaries at the retrieval layer, not the prompt layer. A customer service chatbot should never have unscoped access to a document store that also contains internal risk models, unredacted transaction records across all customers, or product terms for jurisdictions the customer is not eligible for. If retrieval pulls in something out of scope, no amount of prompt instruction reliably prevents the model from surfacing it, because the content is already in context by the time the model generates a response. 

The practical implementation is a query-time authorisation check against the retrieval index — the same pattern used for row-level security in a database, applied to vector or hybrid search. Segmenting knowledge bases by regulatory jurisdiction, product line, and customer tier, and enforcing that segmentation before retrieval executes, is what prevents an edge-case query from ever reaching content it shouldn't. 

Output Validation: Treating the Model's Response as Untrusted Input 

Once the model generates a response, it should be validated before it reaches the customer — not because the model is unreliable in the aggregate, but because a single unchecked response is a compliance incident. This validation layer typically covers three concerns: 

Does the response's claims trace back to the retrieved source material, or has the model introduced information not present in context? Automated grounding checks — comparing generated claims against retrieved passages — catch hallucination before it reaches a customer, and are considerably more reliable than asking the model to self-report confidence. 

Does the response cross into advice categories that require a licensed advisor — investment recommendations, specific tax guidance, credit decisioning rationale? This is enforced with a classifier or rules layer that operates independently of the generation model, checking the output against a defined taxonomy of prohibited response categories before release. 

Are mandatory disclosures present where regulation requires them? This is deterministic and should be enforced deterministically — template injection or a post-generation check, not a hope that the model remembered to include them. 

None of this is exotic engineering. It is the same defence-in-depth principle applied to model output that has applied to user input validation for two decades. The output of an LLM is not privileged text; it is untrusted content that happens to be well-written, and it should pass through the same scrutiny any other untrusted content would. 

Escalation Paths: Designing for the Handoff, Not Just the Refusal 

A guardrail that only says "no" is incomplete. In a banking context, the response to an out-of-scope or high-risk query needs a defined path to a human, not a dead end. This requires the escalation logic to be designed as part of the conversation architecture from the outset — what triggers a handoff, what context transfers with it, and what the customer experiences during the transition. 

Well-designed escalation triggers on more than explicit refusal categories. Confidence thresholds on the grounding and classification checks described above, repeated rephrasing of a blocked query (a signal the customer is trying to route around a guardrail rather than genuinely confused), and specific regulatory trigger phrases — vulnerability disclosures, complaint language, fraud indicators — should all route to a human queue with the full conversation context attached, so the customer does not have to repeat themselves. 

The architectural requirement here is that escalation state and conversation context are first-class citizens in the system design, not an afterthought bolted onto a support ticketing integration after the chatbot is already in production. 

Regulatory Context Shapes the Architecture, Not Just the Content 

Under the EU AI Act, a customer-facing banking chatbot providing information that influences access to financial services or creditworthiness assessment can fall into higher-risk classification tiers, which carry documentation, transparency, and human oversight obligations. DORA's ICT risk management requirements extend to AI components used in customer-facing systems, meaning the retrieval infrastructure and validation layer are themselves subject to operational resilience testing, not just the customer-facing conversation. GDPR considerations apply directly to what enters the retrieval context and what the model is permitted to reference about an individual customer. 

These are not compliance footnotes to address after the system is built. They shape which architectural pattern is appropriate before a line of integration code is written — which is why this work is designed alongside the institution's risk and compliance function from the scoping stage, not handed to them for sign-off after delivery. 

The pattern across every layer described here is the same: guardrails that hold up under regulatory scrutiny and adversarial pressure are built into the system architecture, evaluated independently of the model's own outputs, and designed with the assumption that someone — an auditor, a regulator, or an incident response team — will need to trace exactly why a given response was, or wasn't, allowed through. Prompt engineering has a role in this picture. It is not the picture. 

For institutions evaluating LLM deployment in customer channels, the right question to ask a delivery partner is not "how good is your prompt." It is "show me your retrieval scoping model, your output validation pipeline, and your escalation architecture" — and a partner who can answer all three in specifics, before the model has even been selected, is the one who has done this before. 

LLM Guardrails in Customer-Facing Banking Chatbots 

LLM guardrails for banking chatbots: retrieval scoping, output validation, and escalation architecture that hold up under EU AI Act and DORA scrutiny 

Where Prompt Engineering Ends and Architecture Begins 

Every major card network has now announced an agentic commerce protocol. Visa launched its Intelligent Commerce initiative (Trusted Agent Protocol) in late 2025. Mastercard followed with Agent Pay, then extended it to machine-to-machine micropayments. Google, Mastercard, and a coalition of processors including Worldpay, Fiserv, Checkout.com, and Adyen have co-developed a shared standard for making agent authorization explicit and auditable. 

The announcements read like a settled future. The regulatory foundation underneath them is not settled at all — and that gap is precisely where a BA's job gets interesting. 

For institutions building or evaluating support for agent-initiated payments, the core question isn't "can our systems technically process a transaction an AI agent submitted." Most payment rails can already do that; a transaction is a transaction to a settlement engine. The real question is a business analysis question: who is legally authorizing this payment, how is that authorization evidenced, and does your current requirements model even have a field for it? 

 The Authorization Gap Your Requirements Docs Don't Cover 

Existing payment authorization frameworks — PSD2's Strong Customer Authentication regime chief among them — were built around a foundational assumption: a human is present at the moment of authorization, and that human's authentication (something they know, have, or are) is the proof of consent. Agentic payments break that assumption cleanly in half. The human isn't present at the transaction moment. They delegated authority earlier — sometimes minutes earlier, sometimes as a standing instruction — and an autonomous system is now acting on a scope of permission that was granted in the past, not consent given in the present. 

PSD2 itself is technologically neutral and doesn't prohibit this, but it also doesn't define how "demonstrable consent" is satisfied when the consenting party is a delegated agent rather than the account holder acting in the moment. This is not a hypothetical gap for your requirements team to flag someday — it's the exact question every card network's new protocol is trying to answer with cryptographically verifiable mandates. If your institution's current account opening and payment authorization business rules only have a binary model — "customer authenticated, yes/no" — that model needs a third state: agent acting under a scoped, time-bound, revocable mandate on the customer's behalf. 

 From Know-Your-Customer to Know-Your-Agent 

This is the requirement that will land on a BA's desk before it lands on an engineer's. The emerging industry framing is "Know-Your-Agent" (KYA) sitting alongside — not replacing — Know-Your-Customer. In practice, this means your onboarding and risk frameworks need to answer a new set of questions that don't map cleanly onto your existing customer due diligence templates: 

What is the verifiable identity of the agent itself, distinct from the identity of the customer who deployed it? Emerging standards use cryptographic identity credentials for this — a verifiable "passport" for the agent, separate from the account holder's KYC record. 

What is the scope of the mandate the agent is operating under — spend limits, permitted merchant categories, time bounds, revocation conditions — and where is that mandate stored and audited? 

What happens when an agent acts outside its mandate? Is that an unauthorized transaction (triggering your existing fraud and reversal workflows), a contractual breach by the agent provider, or something your current dispute-handling process has no category for? 

None of this is abstract policy discussion. It is a concrete gap in your requirements traceability matrix, your fraud rulebook, and your customer dispute intake process, and it needs business rules defined before engineering can build against them. 

 Compliance-by-Design, Not Compliance-Bolted-On 

The EU AI Act entered into force in August 2024 with a phased implementation timeline. Prohibitions on certain AI practices have applied since February 2025, and obligations for general-purpose AI models since August 2025. Critically for financial institutions, the obligations for high-risk AI systems — the category most relevant to payment agents — take effect from August 2026. The Act applies horizontally across sectors, meaning payment agents deployed by or on behalf of an EU institution fall within its risk-based framework regardless of what the payment-specific regulation eventually says. 

That framework requires risk classification, human oversight mechanisms, transparency, and auditability for the AI systems involved. For a BA, this translates into concrete deliverables well before a single line of orchestration code is written: a documented risk classification for any agent-facing payment capability, a defined human-oversight checkpoint (not a rubber stamp — an actual point where a human can intervene before irreversible settlement), and an audit trail specification that a regulator or auditor could actually follow after the fact. 

The institutions handling this well are treating compliance requirements as an input to the architecture, not a review gate applied after the technical design is already locked. That means the BA's requirements-gathering phase needs direct input from compliance and risk stakeholders on mandate scope definitions, escalation thresholds, and audit trail granularity — captured as functional requirements alongside the payment flow itself, not appended as a compliance annex afterward. 

What This Changes About Fraud and Dispute Handling 

Traditional fraud detection models are built on human behavioral patterns — typing cadence, device familiarity, transaction timing consistent with a person's habits. An agent transacting on a customer's behalf breaks those pattern-matching assumptions, because the agent's "behavior" is fast, consistent, and doesn't look like any human's spending pattern at all. This isn't a future problem to schedule for next year's roadmap; it's a requirement to raise now with your fraud and risk teams, because retrofitting fraud rules after an institution has already onboarded agent-initiated volume is a materially harder project than designing for it up front. 

Dispute handling has a parallel gap. When a customer disputes a transaction today, the investigation traces back to a single authenticated session. When an agent initiated the transaction under a mandate granted days earlier, the investigation needs to trace two things: whether the agent acted within its granted scope, and whether the mandate itself was validly and knowingly granted by the customer. Your current dispute workflow almost certainly has no branch for this, and building that branch is a business process design exercise before it's a system change. 

Agentic payments in 2026 are still, by most credible industry assessments, more pilot than production at scale — the marketing announcements have outpaced actual transaction volume. That's precisely the window in which requirements work is most valuable, before institutional muscle memory hardens around a half-built process. 

The practical starting point for a BA-led initiative is not a technical proof of concept. It's a stakeholder mapping exercise across compliance, fraud, legal, and product to answer three questions together: what does a valid agent mandate look like for our institution, what is our tolerance for irreversible agent-initiated settlement without a human checkpoint, and what does our dispute process need to look like when the "who authorized this" question has two possible answers instead of one. 

Get those answers documented and agreed before the card network protocols your institution adopts force the questions to be answered under deadline pressure instead. 

Agentic AI in Payments

Agent-initiated payments challenge PSD2 authorization assumptions. What banks need to define now — from mandate frameworks and Know-Your-Agent to fraud models and dispute handling. 

Agent-initiated payments break PSD2 authorization assumptions. What banks need to define for mandates, KYA, and fraud models now. 

What "Agent-Initiated Transactions" Mean for Your Architecture 

Most KYC pipelines are designed for the average case and deployed against the worst case. A pipeline that comfortably processes a few hundred onboarding requests an hour falls over the moment a marketing campaign, a product launch, or a seasonal surge sends volume up by an order of magnitude. When that happens mid-liveness-check, the failure isn't graceful — it's a customer staring at a spinner, a support queue filling up, and a compliance team asking why verification records are incomplete. For a Java backend team building this pipeline, the interesting engineering problem isn't calling a document verification API. It's designing a system where document verification, liveness detection, and multi-vendor orchestration hold together when everything is happening at once and nothing is going according to plan. 

The Pipeline Is a Distributed Transaction, Not a Function Call 

The instinct when integrating a KYC vendor is to treat verification as a synchronous call: submit the document, get a result, proceed. That model works in a demo. It breaks in production, because a real onboarding flow typically chains three to five discrete verification steps — document authenticity check, data extraction, liveness detection, face match against the document, and often a sanctions/PEP screen — frequently split across two or more vendors because no single provider is best-in-class at all of them. 

Treat this as what it actually is: a distributed saga with partial failure as the default state, not the exception. Each step should be modeled as an idempotent unit of work with its own retry policy, its own timeout, and its own compensating action. In practice, this means: 

Each verification step publishes its result to a durable store keyed by an onboarding session ID, not just to an in-memory response object. If your orchestrator crashes between step two and step three, you need to resume from persisted state, not restart the applicant's entire flow. 

Every external call is wrapped with a circuit breaker (Resilience4j is the standard choice in the Java ecosystem) tuned per vendor, not globally. A liveness detection vendor having a slow day shouldn't degrade your document verification vendor's circuit. 

Steps that can run concurrently should. Document verification and initial fraud signals (device fingerprinting, velocity checks) rarely have a hard dependency on each other — running them in parallel via CompletableFuture composition, rather than a strict sequential chain, is often the single largest latency win available without touching a vendor SLA. 

The failure mode that actually shows up under load isn't "too slow" — it's cascading queue growth followed by a full outage. A document verification vendor with a hard rate limit will start rejecting requests once you exceed it, and if your pipeline naively retries every rejection immediately, you've built a retry storm that makes the vendor's rate limiting worse, not better. 

Design the ingestion side of the pipeline around a message queue (Kafka fits naturally here given standard EU banking infrastructure patterns) with consumers that pull at a rate matched to each downstream vendor's actual sustained throughput — not their advertised peak throughput, which is rarely achievable in practice. Apply backpressure at the queue consumer level using a bounded semaphore or a reactive stream with explicit demand signaling (Project Reactor's Flux with limitRate is a reasonable fit if your stack is already reactive), rather than letting the JVM's thread pool exhaust itself under a burst. When a vendor's circuit opens, the queue should absorb the backlog and apply an exponential backoff with jitter on retry — not silently drop requests, and not retry so aggressively that recovery is delayed further. 

Capacity planning here should be modeled explicitly against known surge patterns: a new account promotion, a partner integration go-live, a seasonal spike. If your team can't answer "what happens to average latency and queue depth if inbound onboarding volume triples for two hours," that's the gap to close before the next campaign, not after an incident review. 

Multi-Vendor Orchestration Is a Routing and Fallback Problem 

No serious KYC architecture should have a single point of vendor failure. The practical pattern is an orchestration layer that abstracts vendor-specific API contracts behind an internal domain model — a VerificationProvider interface with vendor-specific adapters — so that vendor failover, A/B testing across providers, or a full vendor migration doesn't require touching business logic in the onboarding flow itself. 

This orchestration layer needs to handle three distinct failure categories differently: 

Transient vendor errors (timeouts, 5xx responses) should retry against the same vendor with backoff, bounded by a maximum attempt count tied to your applicant-facing SLA. 

Vendor unavailability (open circuit, sustained failure) should fail over to a secondary vendor where one exists, with the routing decision logged as a distinct event — this matters for reconciliation, since a secondary vendor may return a differently structured confidence score that downstream fraud scoring needs to normalize against. 

Ambiguous verification results (low-confidence liveness match, partial document data extraction) should route to a manual review queue rather than either auto-approving or auto-rejecting. This is where a lot of pipelines under-invest: building the automated path well and treating the manual review escalation as an afterthought, when in practice a meaningful percentage of legitimate applicants will land there under any realistic confidence threshold. 

What This Means Under the Coming Regulatory Baseline 

This architecture isn't just an engineering nicety — it's about to become closer to a regulatory expectation. The EUDI Wallet framework under eIDAS 2.0 requires every EU member state to make a compliant digital identity wallet available by the end of 2026, and the incoming Anti-Money Laundering Regulation (AMLR), directly applicable from July 2027 under the new AMLA supervisory authority, tightens customer due diligence requirements around electronic identification and reliance on trust services. In practical terms: your orchestration layer needs a VerificationProvider adapter for wallet-based identity attestation sitting alongside your existing document-and-liveness vendors, not bolted on as a separate parallel system later. Teams that build the abstraction layer correctly now — vendor-agnostic, wallet-ready, and designed to absorb a new verification method without a rearchitecture — will treat wallet integration as adding one more adapter. Teams that hardcoded a single vendor's API contract into their onboarding service will be doing a structural rewrite against a hard compliance deadline. 

Building for the Surge You Haven't Seen Yet 

The teams that get this right design the pipeline once, for the peak they expect to eventually hit, rather than scaling reactively after an incident. That means persisted, resumable state at every step; vendor abstraction that treats failover as a first-class path rather than an edge case; backpressure tuned to real vendor throughput rather than advertised limits; and a manual review path built with the same rigor as the automated one. Get those four right, and the pipeline holds together whether it's processing typical daily volume or absorbing a surge ten times that size — and it's already shaped to accommodate the identity verification methods regulation is about to make mandatory. 

Digital Identity Verification at Onboarding 

Architecting KYC pipelines for document verification, liveness detection, and multi-vendor orchestration that scale under onboarding surges 

Architecting KYC Pipelines That Don't Break Under Load 

PSD2 gave Europe's banks seven years to build open banking APIs. Most of that time was spent discovering what the directive left unspecified. Fallback interfaces that technically satisfied the letter of the rule while frustrating third-party providers. API performance that degraded under load with no defined consequence. Consent cycles that forced re-authentication every 90 days regardless of user experience cost. PSD3 and its companion regulation, the PSR, are not a light revision of this framework. They are a direct response to those gaps, and several of the changes land squarely on the integration layer your engineering team maintains today. 

The legislative package reached political agreement between the European Parliament and Council in November 2025, with compromise texts published in April 2026. Formal publication in the Official Journal is expected in the second half of 2026, after which most provisions apply roughly 21 months later — putting practical compliance deadlines around 2028, with Verification of Payee provisions following on a slightly longer runway. That sounds distant. For a bank running a multi-year system architecture, it is not. Decisions made in the next planning cycle about API gateway design, consent management, and monitoring infrastructure will determine whether 2028 is a controlled migration or a scramble. 

The Directive/Regulation Split Changes Where Rules Live 

PSD2 was a single directive, transposed into national law with meaningful variation across member states. That variation is precisely what PSD3 addresses. The new package splits into two instruments: PSD3 itself, a directive governing licensing, authorisation, and supervision (merging the previously separate payment institution and e-money institution regimes); and the PSR, a regulation that applies directly across all member states without national transposition. 

For your architecture team, this split matters practically. The PSR is where the open banking API obligations live — dedicated interface requirements, performance standards, Strong Customer Authentication rules. Because it's a regulation rather than a directive, there's no waiting for national implementing legislation and no risk of your jurisdiction's transposition diverging from a neighboring market's. If your bank operates across multiple EU jurisdictions, this is meaningfully good news: the API-facing rules should be identical everywhere, which simplifies a integration layer that previously had to account for country-specific quirks. 

Dedicated APIs Become Mandatory, Not Just Preferred 

Under PSD2, banks could theoretically maintain a fallback interface — often a modified customer-facing channel — alongside or instead of a dedicated API, provided certain exemption conditions were met. In practice, this created a two-tier open banking landscape: some banks built genuinely robust dedicated APIs, others maintained the bare minimum needed to qualify for a fallback exemption. 

The PSR closes this loophole. Dedicated APIs become mandatory for account servicing payment service providers, with the fallback/screen-scraping exemption pathway removed. This is a structural requirement, not a best-practice recommendation, and it has direct implications for any bank whose integration layer was built around meeting exemption criteria rather than around building a genuinely production-grade API. 

API Performance Gets a Parity Standard — With Real Ambiguity Attached 

This is the provision your engineering leadership should be tracking most closely. The PSR requires that dedicated APIs perform at a level of service equivalent to the bank's own customer-facing digital channels. That's a meaningful shift from PSD2's more generic non-discrimination language: it converts open banking API availability and latency from a compliance checkbox into an operational SLA tied directly to your retail or business banking channel's own uptime and response-time profile. 

Worth flagging honestly: the term "equivalent level of service" is not precisely defined in the current texts, and stakeholders across the industry have been pushing the EBA for clarification on what constitutes an acceptable response time. That ambiguity is a design risk, not a reason to wait. Banks that architect their API gateway and monitoring stack now to treat third-party API traffic with the same observability, alerting, and capacity planning rigor as customer-facing traffic will be positioned to meet whatever the eventual technical standard specifies. Banks that continue treating the open banking API as a secondary, lower-priority interface will be retrofitting under deadline pressure. 

Consent Cycles Extend — Reducing Re-Authentication Friction, Not Integration Load 

The AISP consent cycle extends from 180 days to 365 days under the new rules. On the surface this looks like a minor parameter change. Architecturally, it's a meaningful one: your consent management and SCA orchestration components were almost certainly built around a 90-to-180-day re-authentication cadence baked into session and token lifecycle logic. Extending that window reduces friction for end users and third-party providers, but it also means your consent state management needs to correctly handle longer-lived authorizations without introducing security gaps — stale consent that should have been revoked, or token refresh logic that assumes a shorter cycle than the one now in force. 

Verification of Payee Adds a New Real-Time Obligation 

Separate from the open banking API changes, the package introduces Verification of Payee — an IBAN-to-name matching check performed before payment execution, extending protections that already exist for instant credit transfers to a broader set of payment types. This is a new real-time integration point for most banks' payment initiation flow, and it applies on a slightly extended timeline relative to the core open banking provisions. If your PISP integration or payment orchestration layer doesn't already have a pattern for real-time third-party verification calls sitting in the critical path of payment execution, this is a design conversation to have well ahead of the deadline, not adjacent to it. 

What This Means for Your Architecture Now 

None of these provisions are final law yet — publication in the Official Journal is still pending, and national transposition of the directive elements will follow over the subsequent months. But the substance is politically settled, and the direction is clear enough to plan against. Banks that treat 2026 as the preparation year — auditing which parts of their current integration layer relied on PSD2's fallback exemption, stress-testing API gateway performance against customer-channel benchmarks, and reworking consent lifecycle logic ahead of the mandate rather than after it — will meet the eventual deadline as a scheduled migration. The alternative is discovering these gaps during a compliance audit with a hard deadline already in force. 

This is also worth noting separately: FIDA, the Financial Data Access Regulation proposed alongside PSD3 and PSR, remains in trilogue and would extend open-banking-style access to investments, pensions, insurance, and mortgages under a new category of data-sharing obligation. It is not yet part of the confirmed package, but it signals the direction European regulation is heading — open finance, not just open banking. Institutions building their PSD3 integration layer now have a reasonable opportunity to architect for that broader scope rather than treating it as a separate future project. 

What Changes for Your Integration Layer 

PSD3 mandates dedicated APIs and performance parity with customer channels. What banks should change in their open banking integration layer now.

Open Finance APIs Under PSD3 

Designing a payment system for a bank means thinking through every path a transaction could take — not just the one where everything goes smoothly. A downstream service responding slowly. A network hiccup mid-transaction. A client resending a request that already succeeded elsewhere. The mark of a genuinely reliable banking platform isn't that these scenarios never occur — it's that the architecture has already accounted for every one of them. 

That principle has shaped most of the decisions we've made building payment infrastructure for our banking and fintech clients. I want to walk through one of those architectures in detail — not as an abstract diagram, but as a set of decisions we stand behind, because each one was made with a specific outcome in mind. 

The Core Decision: Orchestrate With Full Visibility 

At the center of the system sits a Payment Orchestrator built on the Saga pattern, communicating with domain services exclusively through Kafka. This is a deliberate choice in favor of precision over simplicity: rather than chaining synchronous calls between services, we designed a system that always knows exactly where a payment stands. 

The orchestrator drives every payment through a defined sequence of steps. It publishes commands to Kafka, waits for result events from domain services, and advances or compensates based on what comes back. Business logic lives in one place. Services stay independently deployable. And before executing any step, the orchestrator writes its current status to a Saga State Store — which means it's always crash-safe by design: if it restarts mid-payment, it reads its last known state and resumes exactly where it left off, with no ambiguity about what happened. 

In a regulated environment, "we can tell you precisely where every payment stands, at every moment" is the standard we build to. 

Data consistency in a distributed payment system is the product of several layers working together, each one covering a specific scenario the others weren't designed for. 

It starts at the API Gateway, where every request passes through TLS termination, JWT authentication, WAF filtering, and rate limiting. Immediately behind that sits an idempotency store: before a payment reaches the orchestrator, we check whether the same idempotency key and request hash have already been seen. If they have, we return the cached response instead of processing a duplicate — so a client resending a request after a network delay is handled correctly by design, not by chance. 

Each domain service checks a processed-events record before acting on a Kafka message and marks it done in the same transaction as the business logic itself. That single pattern turns Kafka's at-least-once delivery guarantee into effectively-exactly-once processing at the application layer. 

The Account Service applies row-level optimistic locking on balance writes, so two concurrent modifications are resolved cleanly rather than one silently overwriting the other. 

The write model is strongly consistent; read projections used for dashboards and lookups are eventually consistent with millisecond lag. That's the right tradeoff for a screen, and our architecture keeps that path clearly separate from anything touching a balance decision. 

None of these are exotic techniques. What matters is that they're applied together, deliberately, at the specific points where each one adds the most value — engineered in from the start, not layered on after the fact. 

Auditability by Design, Not by Reconstruction 

For a banking client, being able to show exactly what happened to a payment, and when, is a core requirement — one that shows up in AML investigations, dispute resolution, and central bank reporting. We treat it as a first-class architectural constraint from the outset. 

Every event in the system carries a standard envelope — event ID, event type, payment ID, correlation ID, causation ID, trace ID, timestamp, service ID. Kafka's durable log does double duty here: it's both the message bus and a secondary audit trail. Because of that, the full lifecycle of any single payment can be reconstructed at any past point in time by replaying events from the store — no fragile database snapshots, no piecing together a timeline from scattered logs. Observability tooling on top — Grafana and Prometheus for SLA dashboards and saga-step timings, ELK for full-text search across structured logs — means any payment can be traced end-to-end from a single ID, whenever an engineer or an auditor needs it. 

This is what it means to build a system that produces its own evidence. In a regulated environment, that's what makes a compliance review straightforward rather than stressful. 

One pattern I'd highlight for other technical leaders evaluating payment architectures: real-time processing and synchronous processing aren't the same thing, and treating them as interchangeable is where a lot of unnecessary complexity gets introduced. 

Our system uses a two-phase response model. The client gets an immediate acknowledgement; the final result arrives asynchronously, via webhook or push notification, once the saga completes. That keeps the synchronous path deliberately short — gateway, idempotency check, orchestrator write, response. Kafka's sub-millisecond propagation keeps inter-service latency negligible, and non-critical steps run fully async, never adding weight to the payment path. The result feels instant to the end user, by design. 

Fraud Detection Engineered to Scale on Its Own Terms 

Fraud detection and AML screening run as independent Kafka consumers, which means they scale, deploy, and evolve on their own schedule — without ever adding latency to the payment flow. Every decision they make is recorded as an event carrying its full reasoning payload, so the compliance record is the actual decision trail, captured as it happened, not a summary written after the fact. 

I'm sharing the mechanics of this architecture because I think the details are the point. It's easy for any vendor to claim they build "banking-grade" systems. It takes real engineering depth to show the specific design decisions — precision-tracked orchestration, layered consistency guarantees, built-in auditability, independently scaling fraud screening — that turn that claim into a guarantee. 

This is the standard we hold our own engineering teams to, and the standard we'd encourage any bank or fintech to hold their delivery partners to. Building a payment system that performs well in a demo is one thing. Building one engineered for every outcome, from day one, is what we consider the actual job. 

Robert Tamas is CEO of OceanoBe Technology, a Romania-based software development company building banking, fintech, and payments infrastructure for European and international banks and payment networks. He works closely with clients to provide solution-fit teams of experienced engineers, while his technical background guides his decisions behind the company's core delivery work. 

Engineering Payment Systems Banks Can Trust With Every Outcome  

OceanoBe designs payment systems for banks: Saga orchestration, crash-safe recovery, full auditability, and fraud isolation built in.

Core Decision: Orchestrate With Full Visibility 

Every Angular team building banking dashboards eventually has this argument: do we reach for classic NgRx, with its actions, reducers, and effects, or do we move to NgRx Signal Store and let signals carry more of the state management weight directly? Having built both fraud monitoring views and trading dashboards in Angular, my answer is that this isn't really a "which is better" question. It's a "what does this specific view need" question, and the two tools solve different problems well. 

The Actual Difference, Not the Marketing Version 

Classic NgRx is built around the redux pattern: a single immutable store, actions describing what happened, reducers computing the next state, and effects handling side effects like API calls. It gives you a strict, traceable, time-travel-debuggable flow of state changes. The cost is verbosity — a simple state update touches an action creator, a reducer case, and often a selector, spread across multiple files. 

Signal Store, part of the NgRx ecosystem but architecturally distinct, is built directly on Angular signals. State lives as signals, updates happen through methods you define on the store, and computed values are just computed signals. There's no dispatch, no reducer boilerplate, no store-wide immutable tree unless you want one. It's closer to how a well-organized service with signals would look, but with NgRx's patterns for testability and composition layered on top. 

The real distinction isn't "old NgRx vs new NgRx" — it's centralized, action-traced global state versus localized, signal-native feature state. Once you frame it that way, the decision criteria become obvious. 

Fraud monitoring dashboards are the clearest case I've seen for sticking with classic NgRx, and it comes down to one thing: audit trail and traceability of state changes. 

When a fraud analyst is looking at a dashboard and a case escalates from "flagged" to "under review" to "confirmed fraud," you often need to know exactly what triggered each transition, in what order, and be able to reconstruct that sequence if a regulator or internal audit asks. Classic NgRx's action log is not just a debugging convenience here — it's close to a natural audit trail. Redux DevTools time-travel debugging, which some teams treat as a nice-to-have, becomes genuinely useful when you're trying to reproduce a state sequence that led to a missed or delayed fraud flag. 

Classic NgRx also earns its complexity when state is genuinely shared and mutated by many unrelated parts of the application. A fraud dashboard pulling case status, analyst assignment, risk scores, and alert queues — where updates to one can affect what's displayed in several unrelated components — benefits from having a single source of truth with explicit, traceable transitions rather than several independent stores that need to stay in sync with each other through some other mechanism. 

The honest tradeoff: you pay for this in boilerplate and in onboarding time for developers new to the codebase. I've watched junior developers spend their first two weeks on a team just learning the action-reducer-effect-selector dance before they can confidently make a change. That cost is real, and it needs to be weighed against the traceability benefit, not assumed away. 

High-frequency trading dashboards are the opposite case. When you're rendering live price ticks, order book depth, or position updates that refresh multiple times a second, the overhead of dispatching actions through a reducer pipeline for every tick is not just verbose — it's a genuine performance liability. Signal Store's direct, synchronous update model, combined with Angular's fine-grained reactivity through signals, means updates flow straight to the components that read them, without an action-dispatch round trip for state that doesn't need centralized traceability. 

There's also a change-detection story here that matters in practice. Signals integrate with Angular's newer, more granular change detection in a way that lets you avoid re-rendering an entire dashboard tree when one price ticks. With classic NgRx and the async pipe against observables, you can get similar granularity, but it takes more deliberate structuring of your selectors and OnPush change detection to avoid unnecessary re-renders. Signal Store tends to get you there with less deliberate effort, because the reactivity primitive is the same one Angular's rendering pipeline is built around. 

Signal Store also fits better when state is genuinely local to a feature — a specific dashboard widget's local filter state, a specific panel's expand/collapse state, a component-scoped data fetch. Forcing this into a global NgRx store, with actions and reducers for state nobody outside that widget cares about, is a pattern I've seen add real overhead for no traceability benefit, because there's nothing here that needs an audit trail. 

The Question I Actually Ask on a New Feature 

When a new dashboard view comes up for scoping, the question I put to the team isn't "which state library are we using this sprint" — it's a short checklist: 

Does this state need an audit trail or replay capability for compliance or debugging purposes? If yes, lean classic NgRx. 

Is this state shared and mutated across many unrelated parts of the app, where explicit traceable transitions prevent bugs? If yes, lean classic NgRx. 

Is this state high-frequency, local to a feature, or does it need the tightest possible change-detection performance? If yes, lean Signal Store. 

Would a new developer need to reason about this state's history to understand a bug, or just its current value? History matters → classic NgRx. Current value is enough → Signal Store. 

In practice, most of our newer banking dashboards end up as a mix within the same application: classic NgRx for the shared, cross-cutting, audit-sensitive state (case management, alert queues, user permissions) and Signal Store for feature-local, high-frequency, or purely presentational state (live data feeds, widget-local filters, transient UI state). NgRx's own direction supports this — Signal Store was built to interoperate within a broader NgRx-based application rather than to force an all-or-nothing migration. 

If you're starting a new Angular banking dashboard today with no existing NgRx investment, I'd default to Signal Store for anything feature-scoped and reach for classic NgRx deliberately, and only, when you can articulate a specific reason — an audit or compliance requirement, or genuinely complex cross-feature state — for wanting it. That's a reversal of where the default sat two or three years ago, but it reflects where the tooling and Angular's own reactivity model have moved. The mistake to avoid is picking one pattern out of habit and then forcing every kind of state — from a live tick feed to a fraud case's status history — through the same mechanism, because the two have genuinely different jobs to do. 

Signal Store or NgRx Store

A practical comparison of NgRx Signal Store and classic NgRx for high-frequency Angular banking dashboards like fraud and trading views.

Choosing State Management for Angular Banking Dashboards 

There's a specific kind of dread that comes with testing fraud detection models. Get it wrong in one direction and you're blocking legitimate customers from paying their bills. Get it wrong in the other and you're the reason a bank's loss report has an ugly line item next to it. And unlike most systems I've tested, you cannot fully validate a fraud model before it touches real traffic — the patterns it needs to catch only exist in production, generated by real attackers adapting in real time. A staging environment with synthetic fraud data will never replicate that. 

This is the core problem that makes fraud model testing different from testing most other banking systems, and it's why shadow deployments and champion-challenger frameworks exist: they let you validate against live traffic without giving the new model authority to act on a single transaction. 

Why Traditional Test Environments Fall Short 

In most QA work, I can build a test suite, cover the known edge cases, run it against staging, and sign off with reasonable confidence. Fraud detection breaks that model in a specific way: the "correct" test cases keep changing, because fraud patterns evolve specifically to evade whatever the current model catches. A test suite built last quarter is validating against last quarter's fraud, not this week's. 

There's also a data problem. Real fraud is a small minority class in a sea of legitimate transactions, and synthetic fraud data — however carefully constructed — tends to be cleaner and more obviously "fraudulent" than what actually shows up. Models that test well against synthetic fraud cases routinely underperform against the messier, more ambiguous real thing. I've seen models pass every planned test case and then miss fraud patterns in week one of production that no one on the team had thought to construct a test for. 

None of this means pre-production testing is pointless — unit tests on scoring logic, input validation, feature pipeline correctness, and regression tests against historical fraud cases are all still necessary. It means they're not sufficient, and the team needs a live-traffic validation layer to close the gap. 

Shadow Deployment: Testing Without Consequence 

A shadow deployment runs the new model in parallel with the current production model, scoring the same live transactions, but its output is logged rather than acted on. The production model still makes every decision; the shadow model is a silent observer. 

From a testing perspective, this is the closest thing to a controlled experiment you get in fraud detection. The test plan centers on a few specific comparisons: 

Score distribution comparison — is the new model's score distribution meaningfully different from the current model's, and does that shift make sense given what changed? 

Disagreement analysis — where do the two models disagree, and manually reviewing a sample of disagreement cases tells you whether the new model is catching things the old one misses, or generating noise. 

Latency under real load — a model that scores well in isolated testing can still fail an SLA when it has to score every live transaction alongside the production model without adding perceptible delay to the checkout or payment flow. 

Stability over time — a single day of shadow data isn't enough. Fraud patterns and legitimate transaction volume both vary by day of week and by seasonal cycle, so the shadow period needs to run long enough to see that variation, not just a convenient sample window. 

The test sign-off criteria I push teams to define before the shadow period starts, not after: what disagreement rate is acceptable, what latency ceiling triggers a fail, and what volume of manually-reviewed disagreement cases counts as sufficient evidence. Without that agreement up front, shadow results tend to get interpreted generously by whoever's eager to ship. 

Champion-Challenger: Giving the New Model Limited Authority 

Once a model passes shadow testing, it doesn't go straight to full production authority — that's still too big a jump. Champion-challenger testing gives the challenger model a small, controlled slice of real decision-making authority, typically on a traffic percentage or a specific transaction segment, while the champion (current production model) continues handling the rest. 

This is where testing shifts from passive comparison to active outcome validation, because now the challenger's decisions have real consequences for a subset of customers. The test focus changes accordingly: 

False positive rate on the challenger's live decisions — not projected from shadow data, but measured from actual blocked or flagged transactions and their confirmed outcomes. 

Testing Fraud Detection Models in Production: Shadow Deployments and Champion-Challenger Frameworks

How shadow deployments and champion-challenger frameworks validate fraud detection models against live traffic without exposing customers to risk

All News

Categories

All News

Categories

Do you want to read more?

Subscribe now for our bimonthly newsletter!