Turning complex banking infrastructure into one product.

Every new fintech, bank and rail multiplied the product, not just the integration work.

VictorFi connected fintechs to banks and payment rails through one product layer. Each combination brought its own approval structures, permissions, compliance requirements, reconciliation logic and failure states. Four customers and six rails is twenty-four integrations to build and maintain; routed through one platform it is ten.

Three groups judged the same product differently. Fintech operators wanted speed and simplicity. Bank operations and risk wanted visibility and control. Engineering wanted to support the next customer without creating another version of the product.

We rejected both obvious answers.

Building each bank exactly what it asked for would have fragmented the platform into as many products as customers. Forcing every bank into one rigid workflow would have been clean to build and unusable for any bank whose approval hierarchy differed.

Instead we found the reusable concepts under the different bank implementations and drew the line between what is shared and what is configurable: one transaction model, one permissions framework, one audit trail, with each institution’s approvals, limits and controls applied as configuration.

• Shared core: transactions, payment states, permissions, audit, reconciliation
• Configurable per institution: approvals, limits, rules, compliance, operational controls

Compliance moved upstream, and onboarding became configuration.

Compliance had arrived as a checkpoint after build, which meant late rework and controls that felt bolted on. It moved into product definition, so permissions, approvals and auditability became product behaviour. New institutions were onboarded through configuration rather than engineering, and success, failure and return across ACH, wire, RTP and FedNow all ended in the same reconciliation and audit trail.

Three things we got wrong.

Some abstractions were too rigid: more bank workflows than expected could not fit one shared model, so we separated shared behaviour, configuration and true exceptions. Compliance arrived too late in early work, which is why it moved upstream. And partner timelines moved slower than product timelines, so we split what could ship independently from what needed partner approval or staged rollout.