Global Payroll Platform

Six Markets, Six Problems

Payroll across multiple countries isn’t a single system. It’s six different regulatory environments, six currencies, six vendor integrations — all pretending to be one platform. The old setup was legacy processes and vendor contracts layered on top of each other, and it was starting to show.

Translation Work

The two engineering teams building the platform spoke one language. The payments teams integrating with it spoke another. The business stakeholders just wanted people to get paid on time. I sat in the middle defining technical requirements, which mostly meant translating between those three groups before anyone started building the wrong thing.

The technical layer centered on ISO 20022 XML — the global standard for payment messaging. Every market had its own variations and validation rules and ways to fail. Some vendors supported API, some only did batch SFTP. The integration layer had to handle both because “standardize on API” doesn’t work when the vendor literally doesn’t have one.

Why Build Instead of Buy

We looked at vendor solutions. They couldn’t handle the multi-market complexity without custom work that would cost more than building. So we chose to own the complexity rather than rent it. Not the easy choice, but the one that made sense.

The Stakes

$1.2B in annual payroll across hundreds of thousands of employees, contractors, and vendors. A single failed batch isn’t a bug — it’s people who don’t get paid. That pressure makes you think differently about edge cases.

Where It Landed

Full deployment across all 6 APAC markets. Two engineering teams shipping to a unified platform. ISO 20022 compliance built in from the start. The work is ongoing, but the platform works.