Rabobank’s recent engineering publications reveal a notable shift in how the Dutch bank thinks about technology and software risk.
The traditional emphasis on efficiency, scheduled control checks and central governance is giving way to a model built around resilience, continuous risk signals, reusable engineering platforms and controls embedded directly into technology workflows.
The significance is clear. Resilience is no longer something that can be demonstrated through a periodic test conducted separately from everyday software delivery. It increasingly depends on how applications, data platforms, cloud environments and engineering processes are designed and operated continuously.
Rabobank made that change of emphasis explicit during its ninth Engineer’s Week, held in November of last year.
Writing about the event, Rabobank lead engineer Liezl Asis said organisations had historically optimised for cost efficiency but that “the paradigm is shifting.”
She added: “Security and resilience are now central to policy and strategy worldwide” so the bank’s approach extends resilience beyond internal infrastructure.
Rabobank uses a quarterly Threat Radar to monitor external risks and translate them into potential financial impacts. Its engineering discussion also recognises that resilience must cover vendors and ecosystem dependencies because a disruption at a partner can affect the bank’s own services.
That is closely aligned with the direction of financial regulation. Under operational-resilience frameworks such as DORA, institutions are expected to understand dependencies, test disruption scenarios and demonstrate that important services can continue or recover within acceptable tolerances.
Rabobank’s engineering message goes beyond high-level policy.
At Engineer’s Week, CISO Corence Klop asked more than 900 attendees: “What would happen if the system you work on fails during peak usage?”
The bank’s conclusion was equally direct: “Every team should simulate, plan, and rehearse outage scenarios to ensure continuity when it matters most.”
That language places resilience testing with individual engineering teams rather than treating it as a specialist exercise owned only by a central continuity function.
It also suggests that resilience is becoming a normal software-quality requirement. Teams need to know not just whether an application performs correctly under ordinary conditions, but what happens when a component, vendor, dataset or supporting service becomes unavailable.
“Every team should simulate, plan, and rehearse outage scenarios to ensure continuity when it matters most.”
– CISO Corence Klop
Rabobank’s engineering platform work shows how those requirements can be made scalable.
In an unusually candid April 2026 account of operating a data-governance platform in a large financial institution, Rabobank cloud engineer Gijs Reijn described the realities of managing shared technology inside a regulated environment.
“There’s a version of ‘running data’ that exists in slide decks,” he wrote. “Then there’s the version that exists inside a large financial enterprise. That one has gravity. It has controls. It needs evidence.”
Reijn added: “If you can’t explain who touched the data, how they touched it, and why they were allowed to touch it, then you don’t really have a platform.”
This is a platform-engineering argument with direct implications for QA. The quality of a financial platform cannot be determined only by whether its technical features work.
It must also be possible to establish ownership, trace changes, verify permissions, test policies and demonstrate that the implemented configuration matches the bank’s standards.
Reijn described four expectations: datasets need classifications, access paths require controls, changes need audit trails and exceptions need owners.
The platform team’s role is not to own every dataset, but to create consistent standards and reusable building blocks that help product teams meet those expectations without recreating governance separately.
This is effectively governance delivered as an engineering product. The bank is using opinionated standards, shared templates, documentation, safe defaults and policy-as-code to make controlled behaviour repeatable across teams.
Reijn said Rabobank applies “golden paths” to reduce decision fatigue and uses rules that are “reviewable, repeatable, and testable.”
Policy-as-code is especially significant. A policy expressed through code can be versioned, tested and incorporated into automated delivery processes.
It can also generate consistent evidence showing which rule was applied, when it was applied and whether a change passed or failed. That is very different from asking a tester or risk manager to reconstruct the control history after a release.
Quality risks
Rabobank’s approach also exposes the quality risks created by managed cloud services. A platform-as-a-service provider may introduce features, alter defaults or change configuration options without the bank initiating a conventional software release.
Those changes still need to be assessed because they can affect data access, model serving, logging, retention and the platform’s security model.
Reijn said his team tracks vendor releases, tests behaviours, verifies defaults and updates guidance and documentation. “That’s not pessimism,” he wrote. “It’s how you keep a fast-moving PaaS usable in a regulated enterprise.”
This expands the definition of regression testing. In a cloud environment, regression is not limited to determining whether the bank’s own code continues to work. Teams must also check whether the behaviour of an external platform has changed and whether the current configuration continues to match internal policy.
Rabobank’s work on risk-driven decision-making adds another dimension.
In April 2026, solution architect Mathieu Lastapis (pictured above) described how the bank replaced fixed-interval credit-risk checks with an event-based process.
The architecture turns data changes into business events, evaluates rules and routes decisions through a controlled human-in-the-loop workflow.
The applications were deliberately separated so that different squads could own and change components independently.
Lastapis said the separation made “testing, versioning and future refactoring easier” and allowed teams to add events or change rules without creating unnecessary side effects elsewhere.
Traceability was built into the process. The orchestration layer records outcomes for audits, while incorrect events are corrected by addressing the source data and allowing the pipeline to reprocess automatically.
The broader principle is that controls do not have to operate on a calendar.
Risk changes continuously, cloud platforms evolve continuously and engineering teams release continuously. Testing and assurance therefore need to respond to events, configuration changes and operational signals rather than waiting for scheduled reviews.
THIS SEPTEMBER IN LONDON
REGISTER TODAY – SIMPLY CLICK HERE
Why not become a QA Financial subscriber?
It’s entirely FREE
* Receive our weekly newsletter every Wednesday * Get priority invitations to our Forum events *
REGULATION & COMPLIANCE
Looking for more news on regulations and compliance requirements driving developments in software quality engineering at financial firms? Visit our dedicated Regulation & Compliance page here.
READ MORE
- AI adoption strains JPMorgan testing
- Can banks ‘outsource’ AI accountability?
- HDFC Bank raises testing stakes
- Is observability banking QA’s next discipline?
- Barclays on AI testing, telemetry and kill switches
WATCH NOW
QA FINANCIAL PODCASTS
CLICK HERE TO LISTEN TO OUR EXCLUSIVE CONVERSATIONS
