Technical debt is a term that surfaces frequently in engineering retrospectives and quarterly planning sessions. In banking, it rarely receives the same level of attention in risk committees. That is a governance gap — and one with measurable consequences. 

For CTOs and VPs of Engineering leading technology functions at banks and payment institutions, technical debt is not a development backlog item to be managed at team level. It is an operational risk category with direct exposure to system availability, regulatory compliance, and audit outcomes. Framing it as such is not a rhetorical exercise; it is a prerequisite for securing the investment and organisational priority that remediation actually requires. 

What Technical Debt Looks Like in a Banking Context 

Technical debt accumulates in layers. At the foundation, most established banks carry core banking systems built on COBOL or early-generation Java platforms, extended over decades through undocumented workarounds, custom integrations, and hardcoded business logic embedded in places that make change expensive and risky. 

Above that layer sit middleware components, API gateways, and other applications added during digital transformation efforts — often integrated without full understanding of the underlying system's constraints. The result is dependency chains that are poorly mapped, inconsistently tested, and difficult to modify without triggering cascading failures. 

What makes this operationally significant is not the age of the code itself but what that age implies: degraded observability, brittle integrations, and an engineering team increasingly unable to predict the consequences of change. 

How Technical Debt Manifests as Operational Incidents 

The operational risk taxonomy already in use across banking — people, process, systems, and external events — maps cleanly onto technical debt failure modes. 

System failures and unplanned outages. Aging codebases are disproportionately represented in post-review incidents. When a payment processing system goes down during peak settlement windows, the proximate cause is often an undocumented dependency or an unpatched component that no longer behaves predictably under current load conditions. The cost of a single such incident — in SLA penalties, reputational exposure, and regulatory notification obligations — frequently exceeds the annualised cost of the remediation work that would have prevented it. 

Security vulnerabilities. Legacy systems often use software, libraries, and operating environments that no longer receive security patches. In a threat landscape where financial institutions are actively targeted, an unpatched vulnerability in a core transaction processing component is not a theoretical risk. Under DORA and the NIS2 Directive, the obligation to demonstrate active management of ICT risk extends to legacy infrastructure — not just modern systems. 

Failed regulatory audits and submission errors. Technical debt directly impairs audit readiness. Systems without structured logging, with inconsistent data lineage, or with undocumented processing logic create material gaps when regulators or internal audit teams require evidence of how a specific decision was made or a transaction was processed. PSD2 compliance, EBA reporting requirements, and DORA-mandated ICT risk assessments all presuppose a level of system transparency that heavily indebted codebases cannot reliably provide. 

Technical debt is difficult to quantify precisely, but it is not impossible to bound. Three metrics are particularly useful for communicating operational exposure to non-engineering stakeholders: 

Mean time to recovery (MTTR). Systems with high technical debt consistently exhibit longer recovery times following incidents. MTTR is directly correlated with the readability and modularity of the codebase — both of which degrade as debt accumulates. Tracking MTTR by system or domain over time surfaces where the debt burden is operationally active. 

Change failure rate. The percentage of deployments that require a rollback or emergency patch is a leading indicator of codebase fragility. In legacy banking systems, change failure rates are often multiples of what modern engineering benchmarks would consider acceptable. Each failed deployment carries direct costs in engineering time, rollback complexity, and — where customer-facing systems are affected — potential regulatory notification. 

Deferred maintenance accumulation rate. The volume of known vulnerabilities, deprecated dependencies, and outstanding security patches in a given system gives a snapshot of how quickly exposure is growing. Without active remediation, this number compounds. These metrics, expressed in operational and financial terms, provide the basis for a business case that risk committees and executive leadership can evaluate against other capital allocation decisions. 

The Cost of Deferral vs. the Cost of Remediation 

The most common argument against modernisation investment is cost and disruption. The risk calculus looks different when deferral costs are made explicit. 

A major outage in a core payments system typically costs a European bank between €500,000 and several million euros in direct losses, regulatory penalties, and remediation — before accounting for customer attrition or reputational damage. A significant data breach affecting customer records carries GDPR exposure of up to 4% of global annual turnover. DORA non-compliance, once enforcement matures, introduces further penalty exposure alongside mandatory incident reporting obligations. 

Against those figures, a structured modernisation programme — approached incrementally through strangler-fig patterns, domain decomposition, or targeted re-platforming rather than wholesale replacement — typically delivers a more predictable cost profile and measurable risk reduction at each milestone. The engineering case for incremental modernisation and the financial case for operational risk reduction are, in this context, the same argument. 

Building the Business Case for Modernisation Investment 

The most effective framing for a modernisation business case at executive or board level is not a technical roadmap — it is a risk register entry with quantified exposure and a mitigation cost. For a CTO or VP of Engineering, this means translating engineering assessments into the language the risk function already uses: likelihood, impact, time horizon, and residual risk after mitigation. 

Attach legacy system risk to existing risk appetite statements. If your institution has defined tolerance thresholds for system availability, data integrity, or regulatory compliance, legacy codebases that demonstrably increase the probability of breaching those thresholds belong on the risk register with ownership, remediation timelines, and funding requirements explicitly assigned. 

Technical debt in banking is not a problem that resolves itself through accumulated workarounds. It resolves through deliberate investment decisions made by engineering and risk leadership acting in alignment. At Oceanobe, we work with banks and financial institutions to assess legacy system exposure, define incremental modernisation pathways, and build the technical and commercial case for remediation — structured around the operational risk frameworks that banking executives already use to make decisions. 

Operational Risk in Software 

Technical debt is operational risk. Engineering leaders: how to quantify exposure, tie incidents to debt, and build the modernisation business case

What Banking Executives Need to Understand About Technical Debt 

As a frontend engineer working on banking interfaces, fraud detection can feel like someone else's problem. The model runs somewhere upstream, a decision arrives, and your job is to render it — a declined transaction screen, a step-up authentication prompt, a risk flag in the case management dashboard. What happens between the moment a customer submits a payment and the moment your Angular component receives a response is, in practice, a distributed systems problem of significant complexity. 

Understanding that architecture is not academic. The latency budget, the shape of the decisioning payload, the reliability guarantees of the pipeline — all of these directly affect what you can build on the frontend and how you reason about failure states. This article walks through the architecture of a production-grade fraud detection pipeline, with attention to what it means for the engineers interfacing with it. 

The Latency Budget and Why It Starts with You 

Sub-100ms fraud decisioning is a system-wide constraint, not just a backend target. If the payment gateway expects a fraud decision within 80ms, and your Angular application adds 15ms of network overhead on the request path, the pipeline has 65ms left to do feature computation, model inference, and response serialisation. That budget gets tighter with every layer. 

This means frontend engineers need to be deliberate about where fraud check calls are initiated and how they are structured. Calls should originate as close to the point of transaction submission as possible — not after UI validation layers, not after redundant state checks. Payload size matters too: sending unnecessary fields to the decisioning API adds serialisation overhead on both ends. Work with the backend team to define a minimal, stable contract for the fraud request payload, and treat that contract as a performance artefact, not just an API spec. 

Stream Processing: Kafka and Flink in the Decision Path 

The fraud pipeline begins upstream of your API call. Transaction events enter a Kafka topic the moment they are initiated — often before the user has finished the submission flow. Kafka acts as the durable, high-throughput event backbone: it buffers transaction events, decouples producers from consumers, and provides the replay capability that makes audit trails possible under DORA. 

Apache Flink sits downstream of Kafka, consuming the transaction stream and performing real-time feature computation. This is where behavioural signals are assembled: transaction velocity over a rolling window, deviation from a customer's historical spend pattern, geographic anomalies relative to recent activity. Flink's stateful stream processing allows these features to be computed continuously, without waiting for a batch job to run overnight. 

For the frontend engineer, the implication is that by the time your API call reaches the decisioning service, a significant portion of the feature vector has already been computed. The request you send is not triggering feature computation from scratch — it is triggering a model inference step against a feature set that the pipeline has been maintaining in real time. 

The computed features produced by Flink are written to an online feature store — a low-latency key-value store (Redis and Feast are common choices) optimised for point lookups at inference time. When the decisioning service receives your request, it fetches the pre-computed features for the relevant customer and transaction context from this store, typically in under 5ms. 

Model inference runs on a dedicated serving layer — commonly built on Triton Inference Server or a similar framework — which handles batching, versioning, and hardware acceleration. The model returns a fraud probability score, which the decisioning service then evaluates against configurable thresholds to produce a structured decision: approve, decline, or escalate to step-up authentication. 

What you receive in the API response is the output of this chain. Design your Angular components to handle all three decision states explicitly, including the escalation path. A step-up authentication trigger is not an error — it is a valid, expected response that requires a distinct UI flow. 

Explainability and the Regulator's Requirement 

Regulators operating under PSD2 and the EBA's guidelines on internal governance require that automated decisions affecting customers be explainable. A fraud model cannot simply return a score; it must be able to surface the contributing factors in a form that can be presented to a customer or reviewed by a compliance officer. 

This has direct consequences for the frontend. The decisioning API response in a compliant pipeline will typically include a structured explanation payload alongside the decision — a ranked list of contributing features or risk signals. Your case management interface needs to render this payload in a way that is meaningful to a fraud analyst: not raw feature names from the model, but human-readable labels that map to the underlying signals. 

Build this rendering layer with compliance in mind. The explanation payload is not auxiliary information — in a regulated environment, it is part of the decision record. Treat it accordingly in your data model, and ensure it is preserved and surfaced in audit views. 

Handling Failure States at the Integration Boundary 

Production fraud pipelines are not uniformly available. Model serving infrastructure can experience latency spikes; the online feature store can experience cache misses that force a slower fallback lookup; Kafka consumer lag can introduce delays during traffic peaks. Your integration layer needs to account for these scenarios explicitly. 

Define a clear timeout policy for fraud check calls — 150ms is a reasonable ceiling before falling back to a default policy. That default policy should be defined in collaboration with the risk team, not inferred by the frontend. Common approaches include approving low-value transactions below a defined threshold, routing to manual review, or applying a conservative decline. Whatever the policy, it should be encoded in the backend and returned as a structured response, not handled silently in the UI. 

Instrument your Angular service layer to capture fraud API response times and timeout rates. These metrics belong in your frontend observability pipeline — they are signals about pipeline health that the backend team may not have direct visibility into from your vantage point. 

Fraud detection in banking is not a backend concern that surfaces occasionally in the UI. The frontend is the compliance surface where decisions become visible to customers, analysts, and auditors. Designing that surface well — with explicit handling of all decision states, accurate rendering of explanation payloads, and reliable observability of the integration layer — is as much a part of the fraud pipeline as the Kafka topics and Flink jobs running upstream. 

Understanding the architecture end to end is what makes that design possible. 

Designing Real-Time Fraud Detection Pipelines 

How Angular engineers integrate with real-time fraud detection pipelines — Kafka, Flink, feature stores, and sub-100ms decisioning explained for the frontend layer

Angular engineers integrate with real-time fraud detection pipelines, Kafka, Flink, feature stores, and sub-100ms decisioning explained for the frontend layer

Architecture for Sub-100ms Decisioning 

Legacy systems in banking are not a technical debt problem in the abstract. They are operational reality. COBOL codebases running on mainframes still process a significant share of global transaction volume. The engineers tasked with modernizing these systems face a challenge that is as much epistemological as it is technical: understanding what the code actually does before touching it. 

Large language models, applied through structured prompting workflows, are changing how development teams approach this problem. Not by replacing engineering judgment, but by compressing the time it takes to build it. 

Why Legacy Understanding Is the Bottleneck 

Modernization projects fail less often because of poor architecture choices and more often because the team did not fully understand what they were replacing. A COBOL program written in the 1980s may encode decades of business rule evolution — rate calculations, exception handling, regulatory adjustments — with no external documentation and original authors long gone. 

The traditional approach involves painstaking manual review: reading code, reverse-engineering logic, interviewing whoever still remembers anything about the system. This process is slow, expensive, and produces knowledge that lives in individuals rather than artifacts. 

LLMs provide a different starting point. Given a COBOL program or a legacy PL/I routine, a well-prompted model can produce a structured explanation of what the code does, what its inputs and outputs are, and where the non-obvious decision logic lives. This is not the same as fully understanding the system — but it is a materially better starting point than a blank page. 

The quality of what an LLM produces from legacy code is directly proportional to how well you frame the request. General prompts produce general answers. Structured prompts produce usable ones. 

A reliable pattern for initial code comprehension: 

"You are analyzing a COBOL program from a core banking system. Explain what this program does in plain language. Identify: (1) the business function it performs, (2) the key decision points and conditions, (3) any external files, databases, or system calls it depends on, and (4) any logic that appears regulatory in nature or that handles exceptions. Structure your response as a technical summary followed by a dependency list." 

This prompt works because it constrains the output shape and directs the model toward what engineers actually need: functional intent, control flow, and integration surface. Claude and GPT-4 both handle COBOL reasonably well at this level of prompting, though output should always be reviewed against the source — these models can misread variable scoping or copybook-level definitions if the code is highly fragmented. 

For longer programs, chunking is necessary. Pass individual sections with context about what preceded them: 

"This is section 3 of a 12-section COBOL program. The previous sections handle account validation and interest calculation. Analyze this section and identify what new business logic it introduces, referencing how it builds on or modifies the logic described above." 

Maintaining continuity across chunks prevents the model from treating each section as an isolated unit and losing the thread of the overall program. 

One of the highest-value applications of LLM prompting in legacy modernization is documentation generation — specifically, producing the documentation that should have existed but does not. Prompt pattern for structured documentation: 

"Based on the COBOL program provided, generate a technical specification document in the following format: (1) System Overview — what business process this code supports, (2) Input/Output Specification — all inputs consumed and outputs produced with data types where determinable, (3) Business Rules — all conditional logic expressed as numbered rules in plain language, (4) Known Dependencies — external systems, files, and data structures referenced, (5) Open Questions — logic that is ambiguous or requires human verification." 

The "Open Questions" section is particularly important in banking contexts. LLMs will attempt to interpret ambiguous logic rather than flag it, unless explicitly prompted to surface uncertainty. Making uncertainty a required output section produces documentation that is honest about its own limits — which is far more useful than confident documentation that is wrong. 

Generated documentation should go into version control alongside the code it describes, and into your audit trail. In DORA-regulated environments, being able to demonstrate that you understood a system before modifying it is not just good practice — it may be a compliance requirement. 

Mapping Legacy Logic to Modern Architectures 

Once you have a working understanding of what the legacy code does, the next challenge is deciding what it becomes. This is where prompting shifts from comprehension to design assistance. 

A useful prompt pattern for architecture mapping: 

"Given the business logic described in this COBOL program summary, propose how this functionality would be implemented as a RESTful microservice. Identify: (1) the service boundary — what this microservice owns, (2) the API contract — endpoints, request/response shapes, and error codes, (3) data model — what entities this service manages and how they map from the legacy data structures, (4) integration points — where this service will need to call or be called by other services. Flag any business rules that are complex enough to warrant discussion before implementation." 

This workflow — comprehension prompt, documentation prompt, architecture mapping prompt — creates a structured handoff between understanding the legacy system and designing its replacement. It also produces artifacts that can be reviewed, challenged, and refined by the team before any code is written. 

GitHub Copilot is useful at the implementation end of this workflow, once the architecture is defined. Claude performs better at the comprehension and documentation phases, where longer context windows and more structured output matter. Using both in their respective strengths is a practical division of tooling. 

LLMs do not understand your specific business context. They will explain what COBOL code does in general terms but will not know that a particular field carries a regulatory meaning specific to your institution, or that an exception path was added in 2003 to address a specific audit finding. Human domain knowledge remains the interpretive layer. 

Treat LLM output as a first draft that requires expert review, not a finished artifact. The value is in the speed of that first draft — not in replacing the judgment that must follow. 

For teams working under change management constraints, every LLM-assisted artifact entering your documentation or architecture review process should be clearly attributed and reviewed. Regulatory auditors are increasingly aware of AI-assisted development, and the credibility of your documentation depends on being transparent about how it was produced. 

Pick one program. Not the most critical one, and not the simplest. Pick something representative — a program your team has struggled to understand, that carries real business logic, and where better documentation would have concrete value. 

Run the comprehension prompt. Review the output with someone who knows the system. Note where the model was right, where it was wrong, and where it flagged uncertainty correctly. Use that calibration to refine your prompting approach before scaling it across the codebase. 

Legacy modernization at scale requires institutional commitment. But the prompting workflow that makes it tractable can be validated in an afternoon. 

Using LLMs to Understand and Modernize Legacy Code 

How developers can use LLMs and structured prompting to understand COBOL, generate legacy documentation, and map logic to modern banking architectures

AI Prompting for Real Banking Systems

The phrase "zero-trust" has accumulated enough executive slide decks behind it that engineers could be forgiven for treating it as noise. It is not. For financial institutions operating distributed systems across hybrid infrastructure, zero-trust is a precise engineering posture — one with direct implications for how services authenticate, how traffic is authorised, and how legacy components are incrementally brought into a coherent security boundary. The challenge is not understanding the principle. It is implementing it without replacing everything at once. 

Why Banks Are Forced to Take This Seriously Now 

Regulatory pressure has made zero-trust less of an architectural preference and more of a compliance expectation. DORA, which entered application in January 2025, requires financial entities to demonstrate resilience against ICT threats including insider risk and lateral movement — precisely the threat classes that perimeter-based security fails to address. The assumption that traffic inside the network is trustworthy is no longer defensible to a regulator, and in cloud-native or hybrid environments, the concept of an interior network boundary is increasingly fictional anyway. 

The practical trigger for most banks is cloud adoption. When workloads move to managed Kubernetes clusters or multi-cloud environments, the network perimeter dissolves. Services that once communicated over trusted internal VLANs now traverse infrastructure that neither the bank nor its engineers fully control. Zero-trust fills the gap that perimeter security leaves behind. 

mTLS as the Foundation of Service Identity 

In a zero-trust model, every service call is authenticated. Mutual TLS (mTLS) is the mechanism that makes this tractable at scale. Rather than relying on network position to establish trust, mTLS requires both the calling and called service to present valid certificates — each proving its identity before any payload is exchanged. 

In practice, this means operating a service mesh. Istio and Linkerd are the dominant implementations in Kubernetes environments. The mesh injects sidecar proxies alongside each service container; those proxies handle certificate issuance, rotation, and enforcement transparently, without requiring application code changes. Certificate lifecycle management is delegated to a control plane — typically integrated with Vault or a cloud-native certificate authority — which ensures short-lived credentials and eliminates the manual certificate management that creates long-lived vulnerabilities. 

The engineering discipline required here is not the mTLS configuration itself. It is the consistent enforcement of policy: ensuring that no service-to-service call bypasses the mesh, that permissive modes are never left in place post-deployment, and that observability tooling captures mutual authentication failures as security signals rather than routing noise. 

Identity-Aware Proxies and Token Validation 

Network-layer authentication is necessary but not sufficient. Zero-trust also requires authorisation decisions at the application layer — specifically, verifying that the identity making a request has the right to perform the action being requested, at every hop. 

Identity-aware proxies sit in front of services and evaluate requests against identity context before forwarding them. In banking environments, this commonly means validating a JWT or OAuth 2.0 token carrying claims about the caller — service identity, user context where applicable, and scope. The proxy enforces policy before the request reaches application logic; the application layer should not be the first place that asks whether the caller is authorised. 

The critical implementation detail is that token validation must occur at every service boundary, not just at the API gateway. A token validated at ingress and then passed unchecked through five internal service calls is not zero-trust — it is perimeter security with extra steps. Each service must independently verify the token's signature, expiry, audience claim, and scope. This creates redundancy that may seem excessive until a compromised internal service is the vector. 

The Legacy Problem: Incremental Enforcement 

Most banks cannot implement zero-trust greenfield. Core banking systems running on-premises — often on infrastructure that predates container orchestration by decades — cannot participate in a service mesh or issue mTLS certificates without substantial re-engineering. This does not make zero-trust unachievable; it makes sequencing the critical discipline. 

The practical approach is boundary enforcement at the integration layer. Legacy systems that cannot be modified to participate in mTLS are isolated behind dedicated proxies that handle authentication on their behalf. Calls into those systems are validated and authorised at the proxy boundary; calls out are wrapped with identity context before they reach modern services. The legacy component remains unmodified, but it no longer occupies an implicitly trusted position in the network. 

Migration from this model to full participation — where the legacy system itself presents and validates identity — is typically a multi-year programme. The engineering priority is ensuring that the proxy boundary is treated with the same rigour as any other enforcement point: monitored, tested under failure conditions, and included in incident response procedures. 

The failure mode for zero-trust implementations in banking is not architectural — it is operational. Policies drift. Permissive rules accumulate as teams work around friction. Certificate rotation breaks services that were never properly tested for it. The engineers who implemented the mesh leave, and their successors inherit enforcement gaps they cannot easily audit. 

Zero-trust is not a deployment target. It is a set of invariants — every request authenticated, every authorisation decision explicit, every credential short-lived — that must be maintained continuously. The tooling makes this possible. The engineering culture and operational discipline make it real. 

Zero-Trust Architecture in Banking 

Zero-trust in banking means mTLS, token validation at every layer, and identity-aware proxies — here's what implementation actually looks like in regulated environments

Zero-trust in banking means mTLS, token validation at every layer, and identity-aware proxies — implementation in regulated environments

From Security Principle to Engineering Reality 

Selecting a software development partner is not a procurement exercise. For banks and financial institutions, it is a risk decision — one with direct implications for regulatory standing, operational continuity, and the security of customer assets. The vendor who looks best on paper may not be the one capable of delivering in a regulated environment under real pressure. 

This guide outlines the evaluation criteria that actually matter, and the questions your team should be asking before signing any engagement. 

Delivery Track Record in Regulated Environments 

General software delivery experience does not transfer automatically to banking. Regulated environments introduce constraints — audit trails, change management gates, data residency requirements — that shape how teams plan, build, and release. A partner unfamiliar with this context will discover these constraints mid-project, not in the proposal. 

Ask for concrete examples of projects completed within financial services or similarly regulated industries. Look for evidence of delivery against compliance-constrained timelines, not just on-time delivery in general. Key questions to put to a prospective partner: 

Have you delivered systems subject to PSD2, DORA, or equivalent regulatory frameworks? What change management processes did you operate under, and how did your team interface with the institution's compliance function? 

A credible answer will reference specific frameworks, not generalities. Vague claims about "experience in finance" should be treated as a red flag. 

Security is not a feature to be added at the end of development. It must be embedded into the software delivery lifecycle from day one. When evaluating a partner's security posture, go beyond certifications and assess practice. 

ISO 27001 certification and SOC 2 reports are baseline indicators. What matters more is whether the partner's engineers apply secure coding standards by default, whether threat modelling is part of their design process, and whether automated security testing is integrated into CI/CD pipelines. In banking contexts, a data breach or compliance failure caused by a third-party vendor carries the same reputational and regulatory consequences as one caused internally. 

Questions that surface real security culture: 

How are vulnerabilities handled during development? What is your process when a security issue is identified in a dependency mid-project? Can you walk us through how secrets management and access controls are handled in your delivery environments? 

One of the most underestimated risks in software partnerships is personnel churn. In the context of complex banking systems, institutional knowledge is not easily transferred. When key engineers rotate off a project halfway through, the cost is rarely visible in a status update but shows up clearly in delivery delays, regression incidents, and knowledge gaps at handover. 

Probe how the partner manages team stability and knowledge continuity. Ask: 

What is your average team retention rate on multi-year engagements? How is domain knowledge documented and preserved when team composition changes? Is the core team assigned to our project dedicated, or shared across multiple clients? 

Partners who lack a structured answer to knowledge management are likely to leave your institution holding undocumented systems and dependencies that only their former employees understood. 

Every non-trivial software project encounters unexpected complexity. The differentiator between a reliable partner and a costly one is not whether problems arise, but how they are identified, escalated, and resolved. In banking, the stakes of delayed or mishandled technical risk are concrete: system outages, failed regulatory submissions, or missed go-live windows tied to contractual obligations. 

Evaluate the partner's risk management approach at a process level. This means understanding how they handle architectural decisions, third-party dependencies, and integration risk with legacy core banking systems. Ask for a specific example: 

Describe a situation where a project encountered a significant technical obstacle. How did your team identify it, what was your escalation process, and what was the outcome for the client? 

A trustworthy partner will be specific, acknowledge what went wrong, and describe what was learned. A partner who cannot cite a concrete example of navigating technical adversity likely lacks the depth of experience your engagement will require. 

The most capable development partners in the banking sector share a common characteristic: they approach engagements as participants in your compliance and risk framework, not as external vendors operating outside it. They ask questions about your regulatory context before scoping the work. They surface architectural trade-offs that carry compliance implications rather than defaulting to the fastest path. And they document what they build with the assumption that someone else — an auditor, a regulator, or your own team — will need to understand it years later. 

The evaluation criteria outlined here are not about finding a partner who sounds credible in a sales meeting. They are about identifying who will still be the right choice twelve months into delivery, when the complexity of your environment is fully visible. 

Choosing a Software Development Partner for Your Bank 

How banks should evaluate software development partners: delivery in regulated environments, security posture, team continuity, and technical risk management. 

Banks should evaluate software development partners: delivery in regulated environments, security posture, team continuity, and technical risk management. 

The Questions You Should Be Asking 

Modern banking systems are no longer just codebases — they are increasingly prompt-orchestrated systems where LLMs handle transaction classification, fraud signal interpretation, customer communication, and compliance summarization. As prompts become load-bearing components of production infrastructure, the question is no longer whether to manage them with engineering discipline, but how. 

Prompts Are Code — Treat Them That Way 

In traditional software development, a logic change requires a code review, a test suite run, and a deployment pipeline. In prompt-driven systems, a subtle wording change in a fraud detection prompt can silently shift model behavior across thousands of daily decisions. Yet most teams still store prompts in spreadsheets, Notion pages, or hardcoded strings. 

Prompt-Driven Development (PDD) formalizes the lifecycle of a prompt the same way software engineering formalizes the lifecycle of a function: it is authored, versioned, tested, reviewed, and deployed with explicit controls. 

For banking systems specifically — where regulatory auditability and behavioral consistency are non-negotiable — this discipline is not optional. A prompt that classifies a transaction as high-risk cannot be modified ad hoc by a product manager between deployments. It must carry a version identifier, a change history, and a traceable owner. 

Prompt Versioning: Structural Requirements 

Prompt versioning goes beyond storing text in Git. A production-grade versioning strategy for banking LLM workflows requires: 

Semantic versioning with behavioral contracts 

Each prompt version should declare its intended behavioral contract: what input schema it expects, what output schema it guarantees, and under what conditions it should be deprecated. A fraud_signal_classifier_v2.3 prompt must document whether it handles multi-currency edge cases differently than v2.2 — and that difference must be traceable to a ticket, a review, and a test delta. 

Prompts in production should be stored in an immutable registry — not edited in place. Tools like LangSmith, PromptLayer, or a custom internal registry enforce this. Each version is addressable by hash or semantic ID. Rollbacks become deterministic: reverting to v2.2 is a registry lookup, not a manual copy-paste. 

Prompt templates — the structural logic — should be versioned independently from the runtime context injected at inference time (account metadata, transaction history, regulatory jurisdiction). Conflating the two makes behavioral debugging intractable. 

Unit testing a prompt means asserting that given a specific input, the model produces output that satisfies a defined behavioral contract — not just that it produces some output. 

For a payment dispute classification prompt, a behavioral test suite might assert: 

Given a chargeback claim with a matching merchant refund within 48 hours, the output classification must be RESOLVED, not DISPUTED 

Given an input with a flagged BIN range, the risk score must exceed threshold 0.75 

Output JSON must conform to the declared schema on 100% of test cases 

These are not LLM evals in the academic sense — they are deterministic assertions against curated fixtures, run on every prompt version before promotion. 

When fraud_signal_classifier_v2.3 is a candidate to replace v2.2, it must be run against the full regression corpus of historical inputs with known outputs. Behavioral divergence — even in cases where v2.3 is technically "better" — must be surfaced explicitly and reviewed before deployment. 

A mature PDD pipeline treats prompt promotion with the same ceremony as a service deployment. 

A prompt change targeting a KYC summarization workflow should move through: authoring → lint/schema validation → behavioral test suite → human review gate → staging deployment → shadow mode evaluation → production promotion. Each stage has entry and exit criteria. Shadow mode — running the new prompt in parallel without acting on its output — is particularly valuable in banking, where the cost of a behavioral regression is high. 

Before a prompt reaches a test runner, automated linting should flag structural issues: missing output schema declarations, injection-vulnerable template variables, token budget overruns on known input distributions, or missing jurisdiction-scoping instructions required by compliance policy. 

Prompt deployments must support zero-downtime rollback. When a production incident is traced to a prompt behavioral regression, the resolution path must be: identify the offending version, revert the registry pointer, verify behavioral restoration against the regression suite, and file a post-mortem. The same incident response playbook that governs service outages applies. 

Banking systems built on LLMs inherit all the operational complexity of traditional distributed systems — plus the nondeterminism of language models. Prompt-Driven Development provides the engineering framework to manage that complexity: version prompts as first-class artifacts, test them against behavioral contracts, and promote them through CI/CD pipelines with the same rigor applied to production code. In regulated environments, this is not a best practice. It is a baseline requirement. 

Prompt-Driven Development

Prompt-Driven Development for banking LLMs: how to version prompts as production artifacts, build behavioral test suites, and integrate prompt pipelines into CI/CD

Prompt-Driven Development for banking LLMs: version prompts as production artifacts, build behavioral test suites, and integrate prompt pipelines into CI/CD

Building Banking Workflows with LLMs 

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. 

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

All News

Categories

All News

Categories

Do you want to read more?

Subscribe now for our bimonthly newsletter!