Maksim Yudzeshka is a software engineer at Azati who has shipped features into regulated banking platforms under fixed-release governance. Reviewed by Azati’s Banking & Financial Software Engineering practice.
Short answer. Waterfall in regulated banking persists for good reason: audit trails and fixed release dates are controls, not habits, and you rarely get to remove them. You can still stop missing releases without touching either — hold one cross-functional session before system analysis is finished, so development runs in parallel. On our project, roughly 50-60% of some features were built before sign-off.
Key takeaways
- Waterfall isn’t a legacy accident in banking — audit trails, traceability, and fixed release dates make the sequential model a control, and often a hybrid: strict governance outside, iterative work inside.
- The cost of a defect rises sharply the later it’s caught; the cheapest place to catch a problem is a conversation, not production.
- One cross-functional session — business analyst, system analyst, frontend, backend, designer — held before system analysis finished let development run in parallel; roughly 50-60% of some features were ready before sign-off.
- In an Azati banking engagement, a monolithic lending platform was split into 37 microservices, tripling loan-amendment throughput and cutting case-resolution time by 61%.
- The stakes are real: TSB’s 2018 core migration locked out customers across a 5.2-million base and drew a £48.65m regulatory fine.
Why does waterfall still run in regulated banking?
In 2026 we ran a textbook waterfall on a bank: business analysis, then system analysis, then development, then testing, nothing starting until the stage before it signed off. And yes, it had us closing tickets well past midnight against a date that would not move.
Nobody was doing it wrong. The client’s analysts were thorough; our developers were good. Waterfall in regulated banking isn’t a bad habit — it’s often the only shape governance allows. The model traces to Winston Royce’s 1970 paper, Managing the Development of Large Software Systems, which drew the clean linear diagram and then called building that way “risky.” The industry kept the diagram and lost the warning. The Agile Manifesto (2001) was the reaction, and product teams largely moved on — but regulated banks didn’t, and that’s rational. Formal approvals, traceability, an audit trail for every change, and fixed external deadlines are the point, not the obstacle. Research firm Info-Tech notes that size, complexity, and regulation still push banks toward waterfall, usually as a hybrid: strict governance outside, iterative work inside.
So the process and the deadline were off-limits. The real question was narrower: inside that rigid shell, was there any room to move?
Here’s where the time leaked. In a strictly sequential model, a spec can only be presented once it’s finished — and that presentation is usually the first time five specialists look at the same problem together. That’s when the questions arrive: a scenario that can’t be built as written, a behavior that costs triple what anyone assumed, an interaction that doesn’t fit the interface. None of it is the spec’s fault; it’s the shape of the pipeline. And corrections that late don’t stay put:
Every link is small. Together they explain why competent people, following a reasonable process, still end up doing arithmetic at 9 p.m. about whether tomorrow’s tickets can close before a date that won’t move.
What does a bad banking release actually cost?
In most software, a bad release means a rough week. In a bank it can mean customers locked out, a nine-figure clean-up, and a regulator at the door. That’s why the date is sacred — and late surprises unacceptable.
In April 2018, TSB moved roughly 5.2 million customers onto a new core platform over one weekend. The data migrated; the platform failed on go-live. Customers were locked out across online, mobile, phone and branch banking, and normal service didn’t return for months. TSB paid £32.7m in redress and was fined £48.65m by the FCA and PRA, which found it had failed to organise and control the migration and its outsourcing risk. The regulators’ verdict is the part that matters here: the failure wasn’t a glitch on the night — it was in the planning, control, and testing of the change, problems that existed long before go-live.
Knight Capital, August 2012: a routine trading update didn’t reach every server, and dormant code woke up on the machine that was missed. In about 45 minutes the system fired millions of unintended orders and the firm lost more than $460 million — and was gone within days. The SEC found it lacked adequate controls for deploying new code and for retiring code left on its servers.
Both sit on the expensive end of one curve: the later you catch a problem, the more it costs. That relationship is old and well documented — Barry Boehm’s Software Engineering Economics (1981), the IBM “1:10:100” rule, and NIST’s 2002 study, which put the drag on U.S. financial services alone near $3.3bn a year. The exact “100× in production” multiplier is debated; the shape isn’t. A problem caught in conversation costs a sentence. Caught in production, it costs the code, the retest, the redeploy, and the incident. When the incident is TSB-shaped, “we’ll catch it in testing” isn’t a plan.
The fix: one meeting, before the spec was done
We couldn’t compress system analysis — the bottleneck was never typing speed. It was when the technical team first got to react. So after business analysis, but before system analysis finished, we added one cross-functional session: business analyst, system analyst, frontend, backend, designer. One job — reach shared understanding and surface problems while they were still cheap.
Each role sees different failure modes. Backend flags what data already exists, which APIs can be reused, what’s expensive server-side. Frontend flags component states, async edge cases, and whether the timeline is even real. Design names the states requirements skip — loading, empty, error, confirmation. And the system analyst gets that feedback before finishing the documentation, so scenarios change on paper, not in code. The most valuable output was early agreement on API contracts: frontend and backend settling fields, parameters, and error states ahead of the final spec.
This did not replace system analysis. The analyst still produced the full, formal documentation governance required; the audit trail didn’t change. What changed was timing — and with shared understanding in hand, developers didn’t have to wait.
While the analyst kept writing, developers built components and data models, stood up the agreed contracts, wired frontend to backend, and prepared the main states. By the time analysis wrapped, on some features roughly 50-60% of the implementation was already in place. The job was no longer “start building” but “reconcile against the detailed spec and adjust.” The date finally had room in front of it instead of a wall.
To be clear, this isn’t coding blind — that would be reckless. The whole thing rests on the team agreeing the problem first. If too many unknowns survive the meeting, that’s the signal to keep analyzing, not to start. The line is between “we understand enough to prepare safely” and “we don’t yet know what to build.”
What running in parallel bought us
Mostly, it bought QA time — and everyone their evenings. Testing isn’t the happy path; it’s boundaries, roles, integrations, regressions, the odd sequences real users find. In the old flow, features landed almost at the release line and coverage quietly got squeezed — which, as TSB and Knight Capital show, is exactly where expensive failures hide. Running development partly in parallel meant features were ready earlier against the same fixed window. QA could breathe. And the shorter effective timeline gave us a buffer for closing tails and fixing the inevitable late bugs. Release stopped being an event we braced for and became something closer to a controlled landing. That’s the outcome I’d point to first — it’s a human one.
How we keep a regulated release safe
That one meeting is a small instance of a bigger principle: reduce what can surprise you late, and build the evidence of correctness as you go. In banking engineering, that has a concrete shape. We favour phased, evidence-based modernization over big-bang rewrites — mapping “as-is” processes into clean BPMN, then splitting monoliths without breaking accounting consistency. During core migrations we run parallel accounting ledgers, reconcile automatically, and run high-concurrency regression testing to prove zero ledger drift before cut-over — the opposite of the single-weekend switch that caught TSB out. Compliance isn’t a final sprint either: audit logging, role-based access, signed webhooks, encryption, and human-in-the-loop checkpoints go into daily commits, so a regulator’s “how did this transaction happen?” has an instant answer. That traceability is what SOC 2, PCI-DSS, GDPR, the EU AI Act, and the EU’s Digital Operational Resilience Act (DORA) — binding on financial entities since it entered application in January 2025 — increasingly require.
It shows up in the details that kill late surprises: a consumer-driven contract-testing platform that catches an integration break before release — the automated version of the conversation above — and QA treated as a lifeline, not a gate. On one mortgage platform, our testers traced a 5-7% calculation drift to race conditions under load and brought it to 0% before it ever reached customers.
The pattern isn’t theoretical. A sample from our banking & FinTech portfolio (client names withheld under NDA; metrics cleared for publication): a monolithic lending platform decomposed into 37 microservices (3× loan-amendment throughput, −61% resolution time); cloud-native payment infrastructure rebuilt with Mastercard/Clearbank and a high-consistency ledger; an equipment-leasing platform with 10+ KYC/AML/credit-bureau integrations and qualified e-signatures, followed by 5× sales growth in the Netherlands; a collapsed notification service rebuilt for 2.5M+ users with zero outages; and, on the insurance side, an AI orchestration layer for claims workflows that automates across legacy systems while keeping compliance and human oversight intact — part of our wider insurance and BFSI automation work.
We didn’t invent this — we rediscovered it
Once it worked, the resemblances were obvious. Three Amigos, a practice generally credited to George Dinwiddie, brings business, development, and testing together to kill ambiguity before work starts; Example Mapping (Matt Wynne) structures that into rules, examples, and open questions; and the whole move is Shift Left — discovery earlier in the lifecycle. Our twist was the guest list: BA + SA + FE + BE + Designer, because in a fixed-deadline regulated release the costly surprises are interface, integration, and API problems, not just business ambiguity. We didn’t adopt a framework. We backed into one, chasing a single problem: mismatches between requirements and feasibility, found far too late.
The takeaway isn’t “start development early.” It’s this: you don’t always have to finish one stage to begin the next — sometimes it’s enough to get the right people in a room and make sure they understand the task the same way. We didn’t loosen a single control or touch the governance the bank required. We just stopped treating the space inside the shell as if it were as rigid as the shell itself.
A footnote for 2026. The same team would now lean on AI for much of this build — but the insight is tooling-independent. AI can build the prepared work faster; it can’t decide, for you, that five people should agree on the problem first. And in messy regulated data it has its own failure modes — part of why AI pilots stall around day 90.
Frequently asked questions
Can you run system analysis and development in parallel?
Yes — if one cross-functional session comes first. The business analyst, system analyst, frontend, backend, and designer align on the feature; then developers prepare components, data models, and API contracts against that shared understanding while the analyst finishes the formal documentation. It is parallel work on an agreed baseline, not coding without requirements.
Why does a regulated bank still use waterfall in 2026?
Because audit trails, traceability, formal sign-offs, and fixed external deadlines are non-negotiable in banking. Many banks now run a hybrid: waterfall governance and gates on the outside, iterative work on the inside. The fixed release date is part of that control model, not a defect in it — which is why you optimise within it rather than against it.
How do you keep a core banking migration from becoming the next TSB?
Never big-bang. We map the “as-is” state into strict BPMN, run parallel accounting ledgers during migration, reconcile automatically, and run high-concurrency regression testing to prove zero ledger drift before cut-over — with audit logging and human-in-the-loop checkpoints built in, not bolted on. Cutover is driven by technical readiness, never a calendar date alone.
When should you NOT start development early?
When requirements are still unformed and the business hasn’t decided how the system should behave. If the cross-functional session ends with too many open questions, that is a signal to keep analysing rather than start — otherwise the prepared work is likely to be thrown away, which defeats the purpose.
Shipping into a fixed-deadline, regulated environment? Azati builds and delivers software for banking, insurance, and other regulated industries — with the governance those environments demand and the delivery discipline that keeps releases on schedule.
Sources
Sources. Royce (1970) · Agile Manifesto (2001) · Info-Tech on Agile in banking · NIST Planning Report 02-3 (2002), building on Boehm and the IBM Systems Sciences Institute · FCA/PRA on TSB · SEC on Knight Capital · DORA, Regulation (EU) 2022/2554 · Example Mapping (Wynne); Three Amigos attributed to George Dinwiddie.
