Skip to main content
All work
Financial services2024 — 2025

Industrialising SEPA and card payments at European scale

Two European banks, more than 50 microservices, and deadlines set by the regulator — not by the delivery plan.

Role
Software design engineer
Period
2024 — 2025
Work
SBS (formerly Sopra Banking Software)
  • Payments
  • Cloud
  • Agile at scale
  • Compliance

200+

automated end-to-end tests, validation runs cut by hours

Context

SBS builds software for the banking sector. Two European banks — ASN Bank in the Netherlands and Argenta in Belgium — were transforming their payment capabilities there: SEPA transfers on one side, Visa and Mastercard cards on the other.

The technical ecosystem spans more than 50 cloud-deployed microservices. The organisation mobilised 8 Scrum teams across 3 countries — France, India, the Netherlands — under SAFe, over 40 sprints and 6 program increments.

One characteristic governed everything else: the deadlines were not negotiable. They were set by European regulation, and a delay was not a schedule slip — it was a compliance failure.

Diagnosis

Two dimensions intersected, and their intersection is what explained the pressure.

Technical dimension

Validation runs took hours. The direct consequence: feedback arrived late, often at the end of a sprint, precisely when there is no time left to act on it. In an ecosystem of more than fifty microservices, every change touches several services at once, and the cost of regression testing grows faster than the team.

Organisational dimension

Eight teams, three countries, three time zones and three working cultures. The difficulty was not the velocity of any single team but their synchronisation — and the circulation of a dense business context, that of payment flows and their regulatory constraints.

What limited the ability to meet regulatory deadlines was not the speed of writing code. It was the length of the feedback loop.

Levers

01 — Shorten the feedback loop through automation

Business benefit: meet non-negotiable deadlines without trading away delivered quality.

Development and automation of more than 200 end-to-end tests, cutting hours off validation run times. The gain is not merely machine time: feedback arriving in minutes rather than hours changes when a defect is found, and therefore what it costs to fix.

02 — Treat compliance as a design parameter

Business benefit: avoid late rework, by far the most expensive kind in a regulated sector.

Delivery of more than 100 user stories tied to payment journeys and regulatory requirements, contribution to GDPR compliance work applied to transaction flows, and to the evolution of open banking solutions. Compliance was not handled at the end of the chain but built into business analysis.

03 — Use AI where the context is explicit, and only there

Business benefit: real time savings on context-heavy tasks, without introducing risk on critical paths.

On mapping data from European regulation onto business logic, the gain was substantial: the context is explicit, field semantics are identifiable, correspondences are derivable. Conversely, on complex distributed features — Kafka, proprietary libraries, implicit business context — the limits were real: contextual errors and conclusions that did not respect the chosen methodology. The answer was not longer instructions but smaller task granularity, to keep the output steerable.

Trajectory

Execution ran across 6 program increments and 40 sprints under SAFe, with a cross-team synchronisation cadence aligned to regulatory milestones rather than the internal calendar. I also worked in a V-model on other scopes, which gives a direct point of comparison between the two organisational models.

Results

  • 200+ automated end-to-end tests, validation run times cut by hours
  • 100+ user stories delivered across payment journeys and regulatory requirements
  • 2 European banking institutions supported through their transformation
  • 50+ microservices in the cloud ecosystem contributed to
  • 6 program increments, 40 sprints, 8 Scrum teams, 3 countries

What I took from it

Regulatory constraint is a design frame, not an obstacle. A deadline that will not move forces early decisions and genuine prioritisation. It is uncomfortable, and it is what makes steering legible.

In a distributed system, the limit is almost always organisational before it is technical. The highest-return lever was not writing code faster; it was shortening the delay between a decision and its verdict.

The gain AI delivers is proportional to the clarity of the context it is given. Where the business context is explicit, it is enormous. Where it is implicit and distributed, it is better to split the task than to lengthen the instruction — a principle I now apply to how I frame use cases with clients.