Initial state
Different statuses, errors and retry rules per bank
The same business state could be represented differently by each institution. Some responses were temporary, some final and some required direct clarification before retrying safely.
Production case · Volt.io
Published production experience
Normalizing European PSD2 bank integrations for an Account-to-Account platform handling hundreds of thousands of transactions each month.
The work turned bank-specific behavior into a consistent internal payment process without hiding uncertainty at the integration boundary.
- ~2 years
- focused on European bank integrations
- Hundreds of thousands / month
- handled by the platform each month
01
One payment process across institutions with different semantics.
Each bank brought its own contract, certificate setup, error vocabulary and interpretation of payment status. A generic success-or-failure adapter would lose the information required for safe retries and support.
The integrations normalized those differences while keeping bank-specific behavior explicit at the edge. Mutual TLS and certificates secured communication between the platform and each institution.
02
External APIs that agree on regulation, not behavior.
Constraints
Security and ambiguity had to be designed into the integration
- PSD2 governed the regulated payment-initiation environment.
- Mutual TLS and bank certificates protected platform-to-bank communication.
- Retries could not create duplicate payment attempts.
- Unknown and transitional statuses had to remain visible instead of being guessed away.
Integration strategy
Normalize the contract, preserve the bank-specific evidence
A shared internal model simplified the payment flow, while per-bank adapters retained the details needed to diagnose failures and decide whether an operation could be retried.
My contribution
Bank integrations from contract analysis to production behavior.
For about two years, my work focused almost exclusively on European Account-to-Account bank integrations.
- Integration design
- I translated bank-specific contracts into the shared payment process and designed mappings for statuses, errors and retry behavior.
- Production bank adapters
- I implemented integrations including Swedbank, National Bank of Greece, Boursorama and CBI, alongside banks in other European markets.
- Secure bank communication
- I worked with Mutual TLS, certificates and the operational constraints of a licensed PSD2 environment.
The transaction volume is platform scale, not throughput attributed to one adapter. The security claim is limited to Mutual TLS and certificates in platform-to-bank communication.
Key decisions
Make failure semantics part of the domain contract.
The shared model had to simplify integration without erasing the difference between a retryable state, a permanent failure and an unknown result.
- 01
An adapter per bank
Each external contract remained isolated while exposing one consistent process to the platform.
- 02
Explicit status mapping
Bank-specific responses were translated into internal states without inventing certainty.
- 03
Secure transport at the boundary
Mutual TLS and certificates formed part of the integration lifecycle, not an afterthought.
- 04
Controlled retry and duplicate handling
Retry decisions followed the returned state and protected the payment flow from repeated operations.
Delivery model
A repeatable path for institutions that are never quite the same.
- 01
Interpret the bank contract
Map the payment flow, certificate requirements, statuses, errors and unresolved cases.
- 02
Implement and normalize
Build the adapter and translate its behavior into the common internal payment model.
- 03
Harden failure paths
Exercise retry, duplicate and ambiguous-state handling before controlled production rollout.
Verified production scope
Multiple European integrations inside one payment process.
- ~2 years
- of hands-on work on European bank integrations
- Hundreds of thousands / month
- at the Account-to-Account platform level
No conversion, latency or transaction-success improvement is claimed because no verified comparison baseline is available.
What this proves
Integration ownership in a regulated, financially critical domain.
The work demonstrates secure external integration, explicit failure modeling and the ability to turn many institution-specific contracts into one operable internal process.
Related case studies
Modernizing a marketing automation platform processing up to about 45,000 events per minute.
At roughly 1,000 integrated stores, disk-based event processing and server-by-server scaling were reaching reliability and cost limits. The platform moved to queues and scalable workers while critical PHP and Java components were modernized incrementally.
Automating catalog updates for nearly 10 million automotive products.
Supplier data was incomplete and inconsistent, while each catalog update required days of developer work. I designed an automated architecture that processes weekly TecAlliance deltas after publication and keeps a standardized catalog of nearly 10 million products current.
Your integration boundary
Do external APIs expose risk your internal model cannot hide?
We can map the contract, failure semantics and operational controls needed for a regulated integration.
Discuss a regulated integration