The Engineering Pattern Every Bank Integration Needs

Learn how idempotency keys and server-side deduplication prevent duplicate payments from retries and failures. Includes Java/Spring code for REST and event-driven flows

Idempotency keys and server-side deduplication prevent duplicate payments from retries and failures. Includes Java/Spring code for REST and event-driven flows

Idempotency in Payment APIs  

Most banks that invest in digital transformation do so with genuine intent. The business case is clear, the leadership is aligned, and the budgets are approved. Yet a significant number of these programmes stall, overshoot their timelines, or deliver systems that require another round of modernization within a few years. 

The failure is rarely strategic. Banks understand why they need to change. The failure is architectural — and it tends to happen early, in the decisions made before a single line of production code is written. 

Understanding where these programmes go wrong, and what distinguishes the ones that succeed, is essential for any bank, payment company, or fintech currently planning or mid-execution on a transformation initiative. 

Transformation failures in banking tend to follow recognizable patterns. They are worth naming directly, because they often appear reasonable at the time. 

The first and most damaging pattern is the decision to replace a legacy system entirely before delivering any new value. The logic is appealing: the old system is the problem, so eliminating it should solve everything. In practice, this approach creates a multi-year programme with no early wins, significant integration risk, and a team that is maintaining two systems simultaneously for an extended period. When requirements shift — and in banking, they always do — the new system has to absorb change before it has even stabilized. 

The second pattern is selecting and locking into a technology platform before the team understands the domain well enough to make that decision wisely. Vendor-led transformation programmes are particularly susceptible to this. The platform becomes the constraint, rather than the business requirements, and engineering teams spend more time working around platform limitations than building product. 

Decoupled Architecture Without Domain Understanding 

Microservices and event-driven architectures are well-suited to banking's complexity — but decomposing a system into services requires a deep understanding of the business domain first. Teams that apply service boundaries based on technical assumptions, rather than domain boundaries, end up with services that are tightly coupled in practice despite being technically separate. The communication overhead increases, and the system becomes harder to change, not easier. 

Transformation programmes that treat regulatory compliance as a post-implementation concern consistently run into problems. Compliance requirements — audit trails, data residency, transaction integrity, access controls — are not features to be added at the end. They constrain the architecture from the beginning. Ignoring this early creates expensive rework at exactly the point when the programme is trying to accelerate. 

What the Successful Programmes Have in Common 

Banks that navigate transformation successfully do not have a different set of problems. They have a different approach to the first 90 days, and that difference compounds over time. 

They Start with Incremental Decomposition, Not Replacement 

The most effective approach to legacy modernization in banking is the strangler fig pattern: introduce new capabilities alongside existing systems, route specific flows through new components, and reduce the legacy footprint gradually as confidence grows. This approach delivers value continuously, maintains system stability throughout the transition, and gives teams the space to learn before committing to architectural decisions that are hard to reverse.

Each incremental release provides a feedback loop. Business stakeholders see working software. Engineering teams gain confidence in the new components. Regulatory teams can review changes in manageable scope. The programme builds momentum instead of deferring all value to a distant go-live date. 

They Design API-First from the Beginning 

API-first thinking is not about building APIs for their own sake. It is about creating explicit, versioned contracts between systems before the implementation begins. In banking, where multiple teams, channels, and third-party integrations interact with the same underlying capabilities, these contracts become the stable surface that absorbs change without propagating it everywhere. 

An API-first approach also prepares banks for open banking requirements. Whether PSD2 compliance is already in place or PSD3 readiness is on the roadmap, an API layer that has been designed deliberately from the outset is far easier to extend than one that has been retrofitted. 

 They Define Domain Boundaries Before Service Boundaries 

The most architecturally sound banking systems are built around domain boundaries, not technical convenience. Payments, lending, risk, identity, and product management each have distinct data ownership, lifecycle, and consistency requirements. Services that cross these boundaries introduce coupling that makes both systems harder to evolve independently. 

Teams that invest time in domain modeling — understanding where business concepts begin and end — make better decomposition decisions. This work is slower at the start and faster over the life of the programme. 

They Build Observability Into the Architecture From Day One 

In banking systems, the ability to understand what is happening in production is not optional. Distributed systems fail in non-obvious ways. A payment that does not reach its destination, a reconciliation discrepancy, a timeout that cascades — these issues need to be diagnosed quickly and with confidence. 

Successful programmes instrument their systems from the beginning: structured logging, distributed tracing, metrics that reflect business outcomes rather than just technical health. This investment pays back every time something unexpected happens in production, which in financial systems is a matter of when, not if. 

They Treat Compliance as Architecture, Not Audit 

The teams that handle regulatory requirements most effectively think of compliance as a structural property of the system rather than a checklist to complete before go-live. Immutable audit logs are designed into the persistence layer. Access controls are enforced at the service boundary. Data residency constraints inform the infrastructure topology from the beginning. 

This approach is not more expensive than retrofitting compliance — it is considerably less so, because the architectural implications are addressed when they are cheapest to address: before the system is built. 

Digital transformation in banking is rarely delivered by a single team working in isolation. The complexity of the domain, the scale of the change, and the pace of delivery required typically involve external engineering partners working alongside internal teams. 

The choice of partner has a disproportionate influence on outcomes. A partner with genuine banking domain experience will recognize the failure patterns described above and push back against them early. A partner with strong engineering depth will make sound architectural decisions under pressure. A partner with a track record in regulated environments will understand that compliance and delivery velocity are not opposing forces when the system is designed correctly from the start. 

The most productive partnerships share ownership of outcomes rather than dividing responsibilities cleanly between business and technology. Problems are solved collaboratively, trade-offs are made transparently, and the architecture evolves through continuous dialogue rather than handoffs across a boundary. 

Digital transformation in banking does not fail because banks lack the will to change. It fails because the architectural decisions made at the beginning of a programme create constraints that become progressively harder to escape. A big-bang rewrite, a premature platform commitment, or a service decomposition based on technical rather than domain logic can each set a programme on a trajectory that no amount of downstream effort can fully correct. 

The programmes that succeed make different decisions early. They decompose incrementally. They design API-first. They align service boundaries to domain boundaries. They build observability and compliance into the architecture rather than layering them on afterwards. 

These are not radical ideas. They are well-understood engineering principles applied with discipline in an environment that demands precision. The difference between a transformation that delivers and one that stalls is usually not the technology selected — it is the quality of the engineering judgement applied from day one. 

OceanoBe partners with banks, payment companies, and fintechs across Europe to design and deliver technology transformation programmes. Our engineering teams bring deep domain expertise in banking systems, payment flows, and regulatory-compliant architecture. 

Why Banks Keep Failing at Digital Transformation

How Technology Decisions Made in the First 90 Days Determine Whether Transformation Succeeds or Stalls 

Digital transformation in banking fails early in the architectural decisions made before a line of code is written

and What the Successful Ones Do Differently 

Regulatory frameworks such as PSD3 are designed to define principles, obligations, and expected outcomes. They are not intended to describe system behavior, API specifications, data models, or implementation workflows. One of the primary responsibilities of a Business Analyst in banking is translating regulatory language into actionable requirements that engineering teams can design, build, test, and maintain. 

With the emergence of AI-powered prompting, this translation process can be significantly accelerated. Large Language Models (LLMs) can help identify obligations, structure requirements, generate traceability artefacts, and map regulations to system behavior. The challenge is not whether to use AI, but how to use it in a way that produces accurate, traceable, auditable, and compliant outputs. 

The Gap Between Legal Language and System Design 

Regulatory texts operate at a much higher level of abstraction than technical systems. For example, PSD3 may require organizations to: 

• Ensure explicit customer consent for data access 

• Provide secure and auditable access to financial information 

While these requirements are clear in intent, they remain ambiguous from an implementation perspective. 

A Business Analyst must translate them into: 

AI prompting can support this process by structuring the interpretation of regulatory language and exposing implementation considerations that may otherwise be overlooked. 

The first step is extracting structured requirements from regulatory text. A generic prompt typically generates a summary. A well-designed prompt generates actionable outputs that can be consumed by engineering and compliance teams. 

'Extract technical requirements from the following PSD3 clause: 

- List non-functional requirements such as security, resilience, and auditability' 

• Authentication and authorization requirements 

• Logging and traceability expectations 

The key is guiding the model to separate regulatory intent from implementation details. 

Structuring Requirements for Engineering Teams 

Once extracted, requirements must be organized into a format that development teams can effectively use. Prompting can help categorize requirements into: 

'Convert the extracted requirements into: 

 This produces outputs that are more closely aligned with established software development processes. In practice, clarity at this stage significantly reduces misunderstandings during implementation and testing. 

Traceability is essential in regulated environments. Every requirement should be linked to: 

• The system component implementing it 

• The validation mechanism or test case ensuring compliance 

LLMs can assist in generating initial traceability matrices. 

 Maintaining traceability ensures that no requirement is lost, compliance can be demonstrated during audits, and implementation decisions remain transparent throughout the delivery lifecycle. 

Regulatory requirements must ultimately be translated into observable system behavior. 

• Consent → API authorization checks 

• Auditability → Logging, monitoring, and traceability 

• Data access control → Token-based permissions and access policies 

• Strong Customer Authentication → Identity verification workflows 

Prompting can support this mapping by connecting business requirements with technical implementation patterns, helping bridge the gap between analysis and engineering. 

One of the most valuable applications of prompting is validating whether a proposed solution design satisfies regulatory obligations. 

'Validate the following API design against PSD3 requirements for consent management and data access. Identify gaps, risks, and inconsistencies.' 

• Improve collaboration with architects and developers 

 In practice, this step often reduces costly rework and minimizes compliance-related risks later in the project lifecycle. 

Ensuring Consistency Across Requirements 

Large regulatory frameworks contain numerous interconnected requirements. Common challenges include: 

• Similar rules implemented differently across services 

• Duplicated or conflicting requirements 

• Inconsistent interpretations between teams 

Prompting can be used as a consistency-checking mechanism. 

'Ensure consent management rules are applied consistently across all APIs, workflows, and customer journeys.' 

This helps maintain alignment across products, services, and delivery teams. 

Prompting LLMs for Compliance: Translating PSD3 into Technical Requirements 

AI prompting helps Business Analysts turn PSD3 regulations into technical requirements, traceability matrices, and compliant system behavior

AI Prompting for Real Banking Systems 

UX Is a Domain Problem, Not Just a Design Problem 

In banking applications, frontend development is tightly coupled with domain logic. Forms, workflows, and user interactions reflect rules defined in backend systems: validation constraints, eligibility criteria, transaction limits, and regulatory requirements. 

With the introduction of AI prompting, frontend developers can now generate UI logic dynamically—forms, validations, and flows—based on structured inputs. 

The challenge is not generating UI. It is ensuring that the UI remains consistent with domain rules and backend behavior. 

From a frontend perspective, prompting becomes a tool to align UX with domain logic, not a shortcut for generating interfaces. 

In traditional systems, frontend and backend logic often diverge over time. 

form validations that differ from backend rules 

inconsistent field naming across screens 

outdated workflows that no longer match business processes 

This creates failed submissions, inconsistent user experience, increased maintenance effort.

AI prompting can reduce this drift—if used correctly—by generating UI logic directly from domain-aligned inputs. 

One of the most practical applications of prompting in frontend development is generating forms from structured schemas. Instead of manually defining forms: 

Developers can use prompts based on backend contracts: 

“Generate a form for payment initiation using the following schema: 

This produces UI aligned with backend expectations. 

Schema-driven prompting ensures: consistent field definitions, correct validation rules, alignment with API contracts.

From experience, this reduces discrepancies between frontend and backend significantly. 

Beyond individual forms, prompting can help define entire user flows. 

“Generate a UX flow for loan application with: 

This produces a structured flow that reflects domain logic. 

Prompting becomes a way to model workflows before implementing them. 

Domain language is critical in banking systems. Terms such as “payment,” “transaction,” “authorization,” and “settlement” must be used consistently across the platform. Inconsistent terminology leads to confusion for both users and developers. 

Prompting can enforce domain language by explicitly requiring it: 

“Use domain-aligned terminology consistent with payment systems. 

Avoid generic labels such as ‘operation’ or ‘action’.” 

This ensures that generated UI reflects business concepts accurately, aligns with backend naming, and improves clarity for users.

From experience, consistent language reduces onboarding time and improves usability. 

Prompting for Validation Logic in the UI 

Frontend validation must mirror backend rules. Prompting can generate validation logic aligned with domain constraints: 

“Generate validation rules for a transfer form: 

This produces validation logic that matches backend expectations. 

The benefit is not automation. It is consistency across layers. 

Structuring Prompts for Frontend Consistency 

Effective prompting for frontend development includes: 

domain context (payments, lending, onboarding) 

A well-structured prompt might include: input schema,expected UI behavior, validation constraints, domain terminology. This ensures that generated outputs are usable and aligned with system requirements.

Integrating Prompting into Frontend Architecture 

Prompting should not replace frontend architecture. It should support it. In practice, this means: using prompts to generate initial structures, integrating outputs into component-based systems, validating results against backend contracts.

React or Angular components consume schema-driven configurations 

validation logic is centralized and reusable 

UI behavior remains predictable and testable 

Prompting accelerates development, while architecture ensures stability. 

Banking workflows include many edge cases: insufficient balance, invalid inputs, regulatory restrictions. Prompting must explicitly include these scenarios: 

“Include error handling for insufficient balance and invalid IBAN.” 

This ensures that generated UI handles real-world conditions. 

From experience, ignoring edge cases during design leads to inconsistent user experience later. 

Several issues appear frequently when using AI prompting in frontend development: 

treating prompts as final outputs instead of drafts 

These issues reduce the value of prompting and introduce new inconsistencies. 

Prompting as a Bridge Between UX and Domain 

Frontend prompting introduces a new way to design banking applications. It enables developers to generate UI logic aligned with backend rules, reducing inconsistencies and improving development speed. 

The key is not automation, but alignment. 

Frontend Prompting: Generating Domain-Consistent UX in Banking Apps 

Learn how frontend prompting enables domain-consistent UX in banking apps using schema-driven forms, validation logic, and aligned domain language.

PSD2 introduced APIs into banking. PSD3 and Open Finance extend that model significantly. The scope moves beyond payments into broader financial data sharing, tighter security requirements, and stronger control over customer consent. For engineering teams, this is not a regulatory update. It is a system-wide architectural shift. 

From a technical partner perspective, the challenge is clear: translate regulatory requirements into systems that are secure, scalable, and production-ready. 

From PSD2 to PSD3: What Actually Changes 

PSD3 builds on PSD2 but introduces stricter expectations in several areas: 

stronger authentication and fraud prevention  

improved API reliability and performance  

clearer rules around access to financial data  

expansion toward Open Finance (beyond payments)  

This shifts systems from “API exposure” to platform-level data sharing. From an engineering standpoint, APIs are no longer integration points. They become regulated products. 

API Architecture: From Exposure to Governance 

Under PSD3 and Open Finance, APIs must meet higher standards like consistent availability and performance SLAs , standardized data formats, strong versioning and backward compatibility. This requires moving from ad-hoc API layers to API governance frameworks. 

A production-ready architecture includes: 

API gateways enforcing authentication and rate limiting  

versioned API contracts aligned with regulatory requirements  

monitoring for availability and response times  

From experience, the biggest gap in PSD2 implementations was not functionality. It was lack of consistency across APIs. PSD3 raises the bar by making this consistency mandatory. 

Consent becomes a central component in Open Finance. Systems must capture explicit user consent, define scope and duration of access, allow revocation at any time, and track consent usage across services. This introduces a new architectural capability: consent as a domain service. 

user-consent -> consent-service -> access-token -> data-access 

Consent is no longer a flag in a database. It becomes a first-class entity that governs all data access. A technical partner ensures that consent logic is centralized, auditable, enforced consistently across APIs.

Open Finance extends beyond payments into areas such as: savings and investments, lending and credit data, insurance and financial products. This introduces some cross-domain data sharing challenges: 

Engineering systems must support domain-aligned APIs, standardized data contracts, transformation layers between systems. 

From a delivery perspective, this often requires introducing Anti-Corruption Layers to translate between legacy and modern domains. 

PSD3 reinforces strong customer authentication and secure communication. Technically, this leads to: 

token-based authorization (OAuth2 / OpenID Connect)  

Security shifts from network-level controls to identity-driven architectures. Every request must be authenticated, authorized, traceable. 

From experience, implementing this consistently across services is one of the most complex aspects of compliance. 

Observability and Regulatory Traceability 

PSD3 introduces stricter expectations around monitoring and reporting. Systems must provide: 

This requires centralized logging, distributed tracing across services, audit-ready data pipelines.

A technical partner ensures that observability is built into the system, not added later. 

Regulatory frameworks increasingly define expectations for API performance. This includes: 

Meeting these requirements brings on the need for a scalable infrastructure, caching strategies for high-frequency data, resilience patterns such as retries and circuit breakers. 

From experience, performance issues often appear under real load, not during testing. Designing for scale from the beginning is essential. 

Most banks do not start from a clean architecture. Legacy systems remain central to operations. PSD3 and Open Finance require exposing data from these systems without compromising stability. 

controlled access through integration services  

A technical partner ensures that integration does not create tight coupling or degrade performance.  

Regulated APIs evolve over time. New versions, new data fields, and updated requirements must be introduced without breaking existing integrations. 

This requires structured versioning strategies, backward-compatible changes, and controlled rollout processes. 

From a system perspective, governance becomes part of the architecture. 

Delivering PSD3 and Open Finance capabilities requires coordination across: backend systems, API layers, security frameworks, data platforms. 

A technical partner contributes with key features by: 

supporting delivery in regulated environments  

The focus is not only on compliance. It is on building systems that remain scalable and maintainable beyond the initial implementation. 

Several challenges appear frequently in PSD3 initiatives: 

treating consent as a simple data field  

weak observability and audit capabilities  

Addressing these early reduces risk and avoids rework. 

PSD3 and Open Finance redefine how banking systems expose and manage data. From an engineering perspective, this is not a set of isolated requirements. It is a shift toward platform-based architectures where APIs, consent, and data governance are core capabilities. 

A successful implementation depends on execution. Systems must be designed to handle regulatory requirements while remaining flexible and scalable. 

With the right architecture and delivery approach, compliance becomes more than an obligation. It becomes a foundation for building new financial services. 

Engineering for PSD3 and Open Finance: What Changes Technically 

Understand the technical impact of PSD3 and Open Finance on APIs, consent management, and secure data sharing in modern banking platforms. 

Translating Regulation into Scalable Banking Architectures 

A React Native Developer’s Perspective 

In AI-enabled banking systems, security discussions often focus on backend services, model hosting, and infrastructure controls. In reality, many AI interactions begin on mobile devices. 

React Native applications handle user input, display sensitive financial data, and increasingly integrate AI-powered features such as transaction explanations, chat assistants, and financial insights. This makes the mobile layer a critical security boundary. 

From a React Native developer’s perspective, secure prompting is not an abstract concern. It is a practical responsibility: controlling how user data is captured, structured, and sent to AI systems. 

Prompts in mobile applications are rarely static. They are dynamically constructed using: 

This creates a direct path from user-controlled input to the AI model. Without safeguards, this introduces risks such as: prompt injection, unintended instruction overrides, exposure of sensitive data. 

On mobile, where inputs are less predictable, this risk increases. 

Sanitization is the first layer of defense. React Native applications must validate and control inputs before constructing prompts. This includes: removing unsafe characters, limiting input length, filtering suspicious patterns.

Secure AI prompting in banking mobile apps using React Native, with input sanitization, PII protection, and safe prompt templates.

All News

Categories

All News

Categories

Do you want to read more?

Subscribe now for our bimonthly newsletter!