Why senior engineering matters for regulated software — a PSD2 perspective

Most software fails forgivingly. A bug in a marketing site costs a conversion; a bug in an analytics dashboard costs a quarter of misread numbers. A bug in regulated payments costs the regulator’s letter, the chargeback, the reconciliation gap that takes the back office a week to chase, and — at worst — the suspension. Regulated software is the part of the industry where the cost of a bug is asymmetric, and the seniority bar that the rest of the industry can soft-pedal is non-negotiable.

This post is about why.

The cost of an error scales differently

In a typical web product, a senior engineer is faster, writes cleaner code, and makes fewer architectural mistakes than a junior. The work compounds; the seniority pays off over months or quarters. In regulated payments, the seniority pays off in the first day in production. Strong Customer Authentication implemented incorrectly does not look broken at low volume — it looks fine, until the regulator’s exemption auditor reads the dynamic-linking implementation and finds that the authentication code does not actually bind to the transaction amount and beneficiary. Then every transaction that used that code path is a finding.

The kinds of mistakes that show up in regulated payments are not ones a junior engineer can spot, because they require a model of why the regulation is shaped the way it is. PSD2 dynamic linking is shaped that way because the regulator wants to prevent a class of session-replay attack. Without the model, the implementation looks fine on the unit test, fails on the audit, and is expensive to fix in production because every refunded transaction lands in the back office for reconciliation.

The right people have shipped against this regulator before

Engineers on our team previously contributed to PSD2 integrations across multiple European banks. The credentialing matters less than what it teaches: the way regulated payments actually fails, the kinds of edge cases the audit will read for, the operational discipline you have to bake into the platform from day one because the post-launch cost of retrofitting it is multiples higher.

Three patterns we have learned to engineer for from day one in payments work:

• Auditability as an architectural property, not an operational one. Audit trails that survive a database migration, a service rewrite, a vendor switch. Reasoning traces attached to every authorization decision. Idempotency keys on every external call. The audit is not a feature added when the regulator asks; it is the shape of the system.
• Reconciliation as a continuous concern. End-of-day reconciliation that runs against a single transaction model, not against three vendor exports stitched together. Discrepancy detection in real time, not in the end-of-month close. Settlement validation as a first-class concern, not a back-office function.
• Operations carrying its own evidence. Every alert carries the rule that fired it. Every routing decision carries the logic that selected the rail. Every chargeback carries the trail of the original authorization, the SCA decision, the rail it ran on, the cutoff window it hit, the settlement event that closed it.

Junior engineers do not engineer this discipline by default; they bolt it on when production exposes the gap. The cost of the bolt-on is what makes regulated payments the part of the industry where the seniority bar pays for itself fastest.

Why we don’t dilute regulated work with juniors

Our default engagement model is senior-only. There are software domains where it is reasonable to mix seniority levels — internal tools, marketing surfaces, analytics layers, anywhere the cost of an error is forgiving. Regulated payments is not one of them. The first time a junior engineer ships an SCA implementation that misses the dynamic-linking requirement, the cost of fixing it post-audit makes the seniority salary delta look like a rounding error.

The same logic extends to every regulated software domain we work in: clinical EMR systems, pharmacovigilance backends, GxP-bound life-sciences tooling, NCA-aligned cloud infrastructure (the subject of the companion post). The cost-of-error asymmetry that makes payments unforgiving makes the same case in healthcare and compliance: senior engineers, every line, every commit, every release.

What we tell buyers

When a fintech or a bank or a regulated buyer asks how we engage, the answer is short: a small senior squad, no juniors, the engagement model that fits the work (project, dedicated team, or staff augmentation), and the operational discipline to ship into a regulated environment from day one. Pricing follows from there. Read the Payments & Open Banking service page for the depth, or start a conversation if you have a regulated payments program that needs senior engineering on it.