In banking applications, validation is not a minor concern. It is part of the domain. Every input—payment amount, IBAN, customer data, transaction limits—must be validated consistently and correctly. A mismatch between frontend and backend validation is not just a UX issue. It can lead to failed transactions, inconsistent behavior across channels, and in some cases, compliance risks. 

Yet in many systems, validation logic is duplicated: 

Over time, these implementations diverge. A rule changes in one place but not the others. Edge cases are handled differently. Error messages become inconsistent. 

The result is what teams often underestimate: validation drift. The way out of this is not better discipline. It is better architecture—specifically, contract-driven validation using shared schemas. 

The Root Problem: Duplication of Business Rules 

In traditional frontend-backend architectures, validation is implemented independently in each layer. The backend enforces rules to guarantee correctness. The frontend reimplements them to provide immediate feedback. Mobile applications do the same. 

At first, this seems reasonable. In practice, it creates multiple sources of truth. 

A simple rule such as: “payment amount must be between 1 and 10,000” ends up implemented three times, often with subtle differences. 

Over time, systems accumulate: inconsistent validation ranges, different interpretations of required fields, mismatched error handling. This is not a tooling issue. It is an architectural one. 

API Contracts as the Single Source of Truth 

The core idea behind contract-driven validation is simple: Validation rules should be defined once and reused everywhere. 

API contracts—defined using OpenAPI, JSON Schema, or GraphQL schemas—already describe the structure of requests and responses. With the right approach, they can also define validation rules. 

This schema is not just documentation. It becomes the contract that both backend and frontend must follow. The backend enforces it at runtime. The frontend uses it to validate user input before submission. 

There is no duplication. There is one definition.  

Schema-Based Validation in Angular and React Native 

Modern frontend frameworks can consume these schemas directly. In Angular, libraries such as reactive forms can be wired to schema-based validation. In React Native, similar approaches can be implemented using validation libraries that interpret JSON schemas. 

The result is that validation logic is no longer handwritten. It is generated or derived from the contract. 

automatic updates when contracts change  

Instead of writing validation rules in multiple places, teams focus on maintaining the contract. 

Once validation rules are defined in schemas, they can also drive form generation. A form can be constructed dynamically based on: field types, required attributes, validation constraints, enumerations. 

a numeric field becomes an input with min/max constraints 

required fields are marked automatically  

This approach reduces boilerplate and ensures that forms always reflect the underlying domain rules. It also enables faster development of new features, especially in systems with many forms, such as onboarding or loan applications. 

Avoiding Drift Between Frontend and Backend 

Drift occurs when different parts of the system evolve independently. Contract-driven validation prevents this by enforcing a shared dependency. 

When a rule changes: the schema is updated > frontend applications consume the new version  > backend validation remains aligned.

Versioning becomes critical here. Contracts must be versioned and backward-compatible to avoid breaking existing clients. 

For example new optional fields can be added safely and existing constraints should not be tightened without coordination  

This introduces discipline into how validation evolves across the system. 

Not all validation can be expressed in simple schemas. Some rules depend on context: 

conditional fields (e.g., required only if another field is set)  

cross-field validation (e.g., date ranges)  

domain-specific logic (e.g., account eligibility)  

In these cases, the contract still plays a role. 

Basic validation is handled through schemas, while complex rules are enforced through: backend domain logic, 

explicit API responses, validation endpoints when needed. 

The key is to keep simple rules in the contract and complex rules centralized, rather than duplicating them across clients. 

Even with contract-driven validation, the backend remains the final authority. Frontend validation improves user experience by catching errors early. Backend validation ensures correctness and security. 

Both must rely on the same contract. This creates a layered validation model: 

frontend: fast feedback, contract-based  

backend: authoritative validation, contract-enforced  

This approach eliminates inconsistencies while maintaining system integrity. 

In fintech and banking platforms, the impact of this approach is significant. 

inconsistent user experiences across web and mobile  

It improves: development speed, maintainability, alignment between teams.

Most importantly, it ensures that business rules are applied consistently, which is critical in financial operations. 

Adopting contract-driven validation requires alignment across teams. Backend teams must treat API contracts as first-class artifacts. 

Frontend teams must consume and trust these contracts. Business Analysts must ensure that validation rules are correctly captured in the schema. This shifts the focus from implementation to definition and governance. 

The contract becomes the shared language between teams. 

Shared Validation Logic Across Angular and React Native Using API Contracts 

Avoid duplicating validation logic in frontend by using API contracts, schema-driven validation, and shared rules across Angular and React Native apps.

Eliminating Drift Between Frontend and Backend Rules in Financial Systems

Banking workflows — onboarding, loan approval, settlement, chargeback resolution — all share the same structural problem: they span multiple service boundaries, run for minutes or days, and operate under regulatory constraints where a partial failure isn't just a bug, it's a compliance event. The systems I've worked on in this space make one thing very clear: the cost of getting the orchestration model wrong compounds quickly. 

The saga pattern gets reached for often in this domain, sometimes appropriately, sometimes not. The real skill is knowing when its complexity is actually buying you something. 

A saga is a sequence of local transactions coordinated across service boundaries, where each step has a corresponding compensating transaction that semantically undoes the effect if a later failure requires rollback. It's not a distributed transaction — there's no two-phase commit, no global lock. Atomicity is replaced with eventual consistency and deliberate compensation. 

Two flavours exist. Choreography-based sagas have no central coordinator — each service reacts to events and publishes its own. Orchestration-based sagas (process managers) use an explicit stateful entity that issues commands and tracks progress. In banking, I almost always prefer the orchestrator. Choreography makes reconstruction of a process's current state expensive — you're joining events across multiple services. An orchestrator makes process state first-class and queryable, which is exactly what audits and support queues demand. 

Loan approval — orchestrated saga (happy path) 

When the pattern earns its complexity cost 

Sagas are the right tool when: the workflow spans multiple service boundaries that can't share a database transaction; the process is long-running and must survive restarts; individual steps have meaningful compensating actions; and the business needs to observe process state as a discrete entity over time. Onboarding checks all of these boxes. A KYC provider, credit bureau, document store, and core banking system are four separate services, four separate failure domains, and the process can sit open for days. 

Settlement reconciliation is a useful counterexample. If the reconciliation runs within a single service against a single database, wrapping it in a distributed saga adds surface area with no correctness benefit. A well-structured state machine with idempotency keys on the write operations is the right call. Don't pay the saga tax if you're not getting saga guarantees in return. 

Compensation, retry, and timeout — the tricky parts 

Compensating transactions are harder than they look. The naive assumption is that compensation is the inverse of the original action. In practice, time passes between a step executing and a compensation being triggered. A credit reservation compensated three hours later may have already propagated into downstream reports. The compensation has to handle that — often by issuing a corrective entry rather than a deletion. Design compensations as first-class operations: their own idempotency keys, their own retry logic, their own audit events. A compensation that fails silently is worse than no compensation at all. 

Every operation in a saga — including compensations — must be idempotent. The process manager will retry on transient failures; the downstream service must handle being called twice with the same idempotency key and return the same result. This isn't optional: without it, retry logic becomes a liability rather than a safety net. 

Retry policies need explicit bounds and backoff. Exponential backoff with jitter, a hard cap on attempts, and a dead-letter path for exhausted retries. Unbounded retries on a payment instruction will eventually cause a duplicate payment — a failure mode that's far more expensive than a failed transaction. 

Timeouts are business decisions. How long should a loan approval wait for a credit bureau response before escalating? That's an SLA conversation, not a http.client.timeout value. Model timeouts as explicit events in the process manager: when one fires, it should trigger a defined transition — retry, escalate, compensate, alert — not a silent expiry. Timeouts that disappear into logs without driving a state change are operational debt. 

Invariant enforcement in regulated environments 

Banking processes carry hard invariants: a loan cannot disburse if KYC is not in an approved state; a chargeback cannot close without a linked dispute record. The instinct is to enforce these in the downstream services, but I've seen this pattern break badly when a new team member adds a direct API call that bypasses the workflow. Put the invariant checks in the process manager itself. The business rules stay visible, centralised, and version-controlled alongside the workflow definition. 

Every state transition should be logged with a timestamp, the triggering event, and the actor — whether that's a service identity or a human user. The process state should be queryable as a single authoritative record, not reconstructed from event log joins. When a regulator asks why a specific customer's onboarding was paused for 48 hours, the answer should come from a direct query, not a forensic investigation across three services. 

Sagas give you resilience and auditability at the cost of real operational complexity. That trade-off is worth making for long-running, cross-service, regulated workflows. For everything else, reach for the simpler pattern first — a reliable queue, idempotent writes, and a well-defined state machine will cover more ground than most teams expect. The discipline is in making that call deliberately, not defaulting to the most sophisticated tool in the box. 

Designing Banking Processes for Automation

Distributed banking workflows expose every weakness in naive orchestration design. Here's how to choose the right pattern — and avoid paying the complexity tax when you don't need to. 

Learn when to use sagas in banking workflows and when to simplify, covering orchestration, compensation, retries, and compliance-driven process design. 

When to Use Sagas and When to Simplify 

Banking architectures are rarely greenfield. Behind every modern API, mobile app, or fintech integration lies a core system that was not designed for today’s expectations—real-time processing, flexible data access, and seamless integration with external partners. 

As banks evolve, they face a fundamental challenge: how to expose capabilities through modern APIs without inheriting the constraints of legacy systems. 

This is where the choice between REST, GraphQL, and asynchronous APIs becomes more than a technical preference. It becomes an architectural decision that directly impacts domain integrity, scalability, and long-term maintainability. 

However, choosing the right API style is only part of the solution. Without proper boundaries, modern APIs risk becoming thin wrappers over legacy systems. This is where Anti-Corruption Layers (ACLs) play a critical role. 

The Problem: Legacy Systems Define the API 

In many banks, APIs are built directly on top of legacy cores. The result is predictable: 

APIs expose technical fields instead of domain concepts  

workflows mirror batch-oriented processes  

data structures reflect outdated models  

changes in the core ripple across all consumers  

For example, a “payment API” may simply expose a set of fields required by the core system, rather than representing a meaningful domain operation such as initiate payment or authorize transaction. 

Over time, this leads to tightly coupled systems where innovation becomes increasingly difficult. 

REST remains the most widely used approach in banking. Its strengths are clear: well-understood patterns, strong tooling and ecosystem, compatibility with existing infrastructure, ease of governance and compliance. 

However, REST APIs can become rigid over time. As requirements evolve, endpoints multiply, and clients often need to orchestrate multiple calls to achieve a single outcome. 

When built directly on legacy systems, REST APIs tend to inherit their limitations, exposing data rather than domain intent. 

GraphQL: Flexibility with Responsibility 

GraphQL introduces a different model. Instead of predefined endpoints, clients request exactly the data they need. This flexibility is particularly useful in: complex UI scenarios, multi-channel applications (web, mobile), reducing over-fetching and under-fetching. However, in banking systems, GraphQL must be used carefully. 

Without proper boundaries, it can expose internal data structures too directly, effectively bypassing domain logic. It can also introduce challenges in: 

GraphQL is most effective when layered on top of well-defined domain services—not when used as a direct interface to legacy systems. 

Asynchronous APIs, often implemented through event streaming platforms like Kafka, represent a different category entirely. 

Instead of request-response interactions, systems communicate through events: 

This model is essential for: real-time processing, decoupling services, scaling high-throughput systems, enabling reactive architectures.

Async APIs align naturally with financial workflows that are long-running or distributed. 

They are not a replacement for REST or GraphQL, but a complementary approach for specific use cases. 

Anti-Corruption Layers: Protecting the Domain 

Regardless of the API style, the core challenge remains the same: preventing legacy complexity from leaking into modern systems. Anti-Corruption Layers (ACLs) provide this protection. An ACL sits between the legacy core and modern services, translating: data structures, workflows, error handling, domain concepts.

Instead of exposing legacy models directly, the ACL presents a clean, domain-oriented interface. 

legacy account structures are mapped to domain-level Account models  

batch-oriented processes are translated into real-time operations  

technical error codes are converted into meaningful domain responses  

This ensures that modern APIs—whether REST, GraphQL, or async—are built on clean domain abstractions, not legacy artifacts.

In practice, modern banking systems use a combination of API styles. A typical architecture may include: 

REST APIs for external integrations and partner access  

GraphQL for frontend aggregation and flexibility  

Async APIs for internal event-driven workflows  

All of these interact with domain services that are shielded from legacy systems through ACLs. 

This layered approach provides: flexibility in how services are consumed, consistency in domain behavior, isolation from legacy complexity.

The API style becomes an implementation detail. The domain remains stable.

Real-World Example: Payments Modernization 

Consider a bank modernizing its payments platform. The legacy core handles settlement and account management, but exposes limited, batch-oriented interfaces. 

an ACL that translates between modern commands and legacy operations  

Kafka-based events for processing and notifications  

From the perspective of external consumers, the system behaves like a modern, real-time platform. Internally, the legacy core continues to operate, isolated behind the ACL. This allows the bank to evolve incrementally without disrupting existing operations.

Governance and Compliance Considerations 

In banking, API design must also account for regulatory requirements. This includes: secure access control, auditability of operations, traceability of data flows, compliance with standards such as PSD2/PSD3.

ACLs contribute to governance by centralizing integration logic and providing a clear boundary for monitoring and auditing. 

API styles must be chosen and implemented with these constraints in mind. 

The choice between REST, GraphQL, and async APIs is not about selecting a winner. Each approach serves a different purpose. The real challenge lies in how these APIs are designed and what they expose. 

Without proper boundaries, modern APIs become extensions of legacy systems. With Anti-Corruption Layers, they become gateways to clean, well-defined domains. In banking, where systems must evolve without breaking, this distinction is critical. 

The future of banking APIs is not defined by protocol. It is defined by architecture that protects the domain while enabling change. 

GraphQL vs REST vs Async APIs in Banking 

Compare GraphQL, REST, and async APIs in banking and learn how Anti-Corruption Layers enable modern integration without exposing legacy system complexity.

Designing Integration Layers That Preserve Domain Integrity in Legacy-Driven Environments 

Frameworks such as PSD3 and SEPA 2.0 do not simply introduce new rules. They reshape how systems must behave: how payments are authorized, how data is shared, how consent is managed, and how traceability is ensured. For engineering teams, the challenge is not understanding the regulation in isolation, but translating it into clear, implementable system behavior. 

This translation layer is where Business Analysts, architects, and engineers converge. It is also where many organizations struggle—not because the regulation is unclear, but because the path from legal text to technical implementation is not systematically defined. 

From Legal Language to Domain Understanding 

Regulatory documents are written in legal and business terms. They describe obligations, constraints, and expected outcomes, but rarely specify how systems should implement them. 

strong customer authentication must be enforced under specific conditions  

access to account data must be consent-driven  

third-party providers must be able to interact securely with banking APIs  

For a Business Analyst, the first step is not technical. It is domain interpretation. This involves identifying: the business capabilities affected (payments, identity, access, consent), the actors involved (customers, banks, third-party providers), the conditions under which rules apply.

The result is a set of domain-level behaviors that can be understood across teams. 

Identifying Impacted Domains and Bounded Contexts 

Once the regulation is interpreted, the next step is mapping it to system boundaries. Modern banking platforms are typically organized into domains such as: payments, customer identity, account management, consent and authorization, API access and integration.

Each regulatory requirement affects one or more of these domains. 

Strong Customer Authentication (SCA) impacts identity and payments  

Open banking access affects API gateways and consent management  

Transaction transparency impacts reporting and ledger systems  

The goal is to avoid treating regulation as a monolithic requirement. Instead, it must be decomposed into domain-specific responsibilities, aligned with bounded contexts. This prevents cross-domain coupling and ensures that each team understands its scope. 

Building Traceability from Regulation to Code 

One of the most critical aspects of compliance-driven engineering is traceability. Every requirement derived from PSD3 or SEPA 2.0 must be traceable: from the original regulatory clause, to business requirements, to system design, to implementation and testing. This is often achieved through traceability matrices. 

Regulatory Clause | SCA required for payments above threshold 

System Component | Authentication Service 

Implementation | MFA flow + risk-based checks 

This structure ensures that no requirement is lost during implementation, auditors can verify compliance, teams can assess the impact of regulatory changes. Traceability is not just documentation. It is a control mechanism that ensures alignment between regulation and system behavior. 

Mapping Regulatory Requirements to Microservices 

In microservices architectures, each service is responsible for a specific domain capability. Regulatory requirements must therefore be mapped to services in a way that preserves both autonomy and compliance. 

an Authentication Service handles SCA logic  

a Consent Service manages user permissions for data access  

an API Gateway enforces access control for third-party providers  

a Payment Service ensures that transactions comply with regulatory rules  

The key is to avoid duplicating regulatory logic across services. Instead, responsibilities should be clearly defined and centralized where appropriate. For example, SCA enforcement should not be implemented independently in every service that triggers payments. It should be handled through a dedicated component or shared service. 

This approach reduces inconsistencies and simplifies compliance management. 

Defining Non-Functional Requirements in Regulated Systems 

Regulatory compliance is not limited to functional behavior. It also imposes strict non-functional requirements. These include: 

security: encryption, authentication, secure communication  

availability: systems must remain accessible for regulated operations  

auditability: all actions must be traceable and verifiable  

data protection: compliance with GDPR and data residency requirements  

For example, PSD3 may require: detailed logging of access to account data, secure storage of consent records, real-time monitoring of suspicious activities. 

These requirements influence system design at every level, from infrastructure to application logic. 

In many cases, they shape architectural decisions more strongly than functional requirements. 

From Requirements to Executable Behavior 

Once requirements are mapped to domains and services, they must be translated into executable behavior. This involves: 

defining API contracts that enforce regulatory rules  

implementing validation and authorization logic  

designing workflows that reflect regulatory processes  

ensuring that edge cases are handled correctly  

For example, a payment API may enforce SCA by: checking whether authentication is required, triggering an MFA flow if needed, validating the result before processing the transaction. This behavior must be consistent across all channels—web, mobile, and third-party integrations. 

Compliance cannot be assumed. It must be verified. Testing strategies must include: 

functional tests for regulatory scenarios  

performance tests to ensure compliance under load  

In many cases, compliance scenarios are more complex than standard business flows. They involve edge cases, conditional logic, and interactions between multiple systems. 

Automated testing plays a key role in ensuring that these scenarios are consistently validated. 

Collaboration Between Business and Engineering 

Translating regulation into system behavior is not the responsibility of a single role. 

Business Analysts interpret regulatory intent. Architects define system boundaries and responsibilities. Engineers implement and validate behavior. 

When regulation changes (as it inevitably does) the system must adapt. Without strong alignment between teams, changes become slow, risky, and inconsistent. 

PSD3 and SEPA 2.0 are not just regulatory updates. They are drivers of architectural change. 

They require systems that are secure, transparent, and interoperable. They demand traceability from legal text to code. They force organizations to think in terms of domains, boundaries, and responsibilities. For engineering teams, the challenge is not simply to comply. It is to build systems where compliance is designed in, not added later. 

At OceanoBe, this is where engineering excellence meets domain understanding—transforming regulatory complexity into scalable, maintainable, and trustworthy systems. 

From Regulatory Text to System Behavior: Translating PSD3 & SEPA 2.0 into Technical Requirements 

Translate PSD3 and SEPA 2.0 into technical requirements using domain mapping, traceability, and microservices to build compliant and scalable banking systems. 

How Banking Teams Turn Compliance into Executable Architecture 

Modern banking platforms are increasingly built around event-driven architectures. Payments, fraud checks, ledger updates, reconciliation processes, and regulatory reporting pipelines often rely on streaming systems such as Apache Kafka to move financial data between services. 

This architectural model provides scalability and loose coupling, but it introduces a new challenge: integration reliability. In event-driven systems, issues frequently appear only when services run together under realistic conditions. A Kafka topic may contain malformed events, a consumer may fail to deserialize a message after a schema change, or retry logic may produce duplicate events. 

Traditional unit tests rarely expose these problems. The real behavior of a streaming pipeline emerges only when the full environment—brokers, schemas, databases, and consumers—is running. 

This is where Testcontainers and Kafka Streams become extremely valuable. By spinning up real infrastructure in ephemeral containers, engineering teams can test entire streaming pipelines locally and in CI pipelines with production-like behavior. 

Why Integration Testing Is Critical in Event-Driven Banking Systems 

Financial systems must guarantee deterministic outcomes. When a payment event is published, downstream services such as ledgering, risk engines, or notification systems must process it exactly once and in the correct order. Several categories of issues commonly appear in streaming architectures: 

schema incompatibilities after message evolution 

consumer failures caused by unexpected event structures 

duplicate processing due to retry mechanisms 

incorrect idempotency logic in consumers 

In payment and ledger systems, these issues can have serious consequences. A duplicate event might result in a double settlement, while a deserialization failure might silently drop critical data from downstream processes. Integration testing helps detect these risks before deployment. However, mocking infrastructure often hides the very behaviors engineers need to test. 

Running real infrastructure components during tests is therefore essential. 

Testcontainers is a testing library that allows developers to run lightweight, disposable Docker containers directly inside their test environment. Instead of mocking external systems, tests can launch actual services such as Kafka brokers, databases, or message queues. Each test suite can spin up a fresh environment, run integration scenarios, and then shut everything down automatically. 

This approach provides several advantages:

Testcontainers and Kafka Streams for Reliable Integration Testing 

Test Kafka Streams pipelines using Testcontainers to spin up real Kafka environments and build reliable integration tests for event-driven fintech systems. 

All News

Categories

All News

Categories

Do you want to read more?

Subscribe now for our bimonthly newsletter!