From the IGP Portal at Argentex to ibanq v2 at IFX

Context

Argentex, a listed FX firm, ran its client product on an ageing #angular app. IGP was the planned replacement, and I came in with the React background to kick it off: a greenfield rebuild of the same payments product.

My part, with a small frontend team behind it, was the customer-facing portal: the onboarding and KYC flow plus the banking screens behind it, multi-currency accounts, FX conversion, bulk and mass payments, virtual IBANs, sub-accounts, and team access. It was built in #react, #typescript and #vite, with TanStack Router and TanStack Query from the #tanstack suite.

IFX Payments had followed IGP for a while, and when Argentex entered insolvency IFX bought the product and moved a few key members of the team, me included, across to continue it. IFX then made an unusual call: rather than fold the portal into its existing product, it built ibanq v2 on the portal and ran it alongside its own ibanq v1, redirecting client traffic across gradually rather than in one cutover.

The constraint

A POC and a production banking platform aren't held to the same bar, and the portal had to cross that gap twice, under two owners, with only a few of the original team carrying context across. At Argentex, the frontend and backend contracts were drifting apart mid-build with no automated test net. That was fine while the screens were still taking shape, not for something about to hold real balances and payment instructions.

After the sale the bar rose again: IFX had chosen to build ibanq v2 on the portal and run it next to ibanq v1, its own established customer platform, rather than extend v1. IGP's services moved across to IFX as a whole, so this was not rebuilding integrations from scratch. The big piece was lifting the architecture off Argentex's setup and onto IFX's, then getting ibanq v2 production-ready and tested on it.

On top of that, IFX's live business had to move over, alongside the customers already on the portal, without a flag-day cutover and with a SOC 2 audit on the calendar. Getting an organisation comfortable depending on a codebase it did not write is a longer road than either a routine migration or a greenfield build.

What I did

A few of us carried the portal across both phases. The parts I drove:

1. 1

   End the frontend/backend contract drift

   Shipped an RFC and a schema-driven codegen pipeline: the backend's OpenAPI spec became a typed client, so a breaking API change surfaced as a build-time error instead of a bug report.

2. 2

   Split onboarding into independently-saved stages

   Identity, business details, ownership, documents, and review, each validated on its own with server-side progress, so an applicant could resume days later exactly where they left off.

3. 3

   Set the success metrics before building

   Instrumented completion rate, per-stage drop-off, time to first funded transaction, and error rate by field. Reworking the stages where applicants stalled took completion from the low fifties to 90%.

4. 4

   Get the portal to production standard

   Pushed end-to-end and unit coverage past 90% with #playwright and #vitest, and cut LCP from 3.4s to 1.6s with route-level code splitting, ahead of the move to IFX.

5. 5

   Own the frontend side of the platform migration

   Lifted both the banking screens and the onboarding/KYC flow off Argentex's infrastructure and onto IFX's, then got ibanq v2 production-ready on the new setup.

6. 6

   Migrate identity first

   Hardened the global #auth0 setup (#mfa, session and rotation policies, automated tenant provisioning) as one of the first pieces moved, since unifying identity was a precondition for moving anything else.

7. 7

   Roll out in stages, not one launch

   Internal validation, a limited pilot, client demos, then a phased go-live, migrating clients cohort by cohort so no single release put all ~800 at risk at once.

8. 8

   Considered keeping ibanq v1 for legacy clients

   Ruled out: two live platforms through an active audit would have doubled the compliance surface for no lasting benefit.

The two domains had never shared a backend before the sale; they share one now, with the onboarding/KYC flow and the banking screens both converging on IFX's backend and a single Auth0 identity layer.

With both platforms live, routing came down to one decision per request: whether the client's cohort had moved yet. Cohorts still on ibanq v1 kept hitting it, migrated ones went to ibanq v2, and the split shifted one cohort at a time until the traffic had all moved across.

Outcome

The portal went from a POC to the platform IFX runs its clients on, alongside the ones already on it: around 800 client businesses and more than 4.5k app users between them. The migration ran with zero customer-visible incidents, and the SOC 2 audit passed on schedule.

The pre-launch client demos went well, and once cohorts were live the new onboarding flow was tracking ahead of ibanq v1 on the things that mattered: higher completion, lower per-stage drop-off, and sign-up and transaction volume climbing week on week. Regression escapes fell to near zero once the contract-drift fix and test coverage were in place, and onboarding completion settled around 85%.

The hardening we did early at Argentex, well before the sale, is a big part of why IFX was comfortable building ibanq v2 on a codebase it hadn't written and routing its own traffic onto it.

What I'd do differently

• Push for one canonical name for the portal earlier. Through the handover it was called "the portal", "IGP", and "ibanq v2" depending on who was speaking, and that ambiguity cost real time when working out which clients belonged in which migration cohort.
• Get design help sooner. There was no designer on the IFX side to drive UX and UI, so those calls fell to engineering by default and slowed decisions a designer would have settled quickly.
• Fix the deployment pipeline early. A release cycle ran roughly 15 to 20 minutes, slow enough to discourage the small, frequent releases the migration needed most.