Singapore Just Named the CEO of Its Payment Schemes: the 4 Engineering Roles That Get Scarce Before 2027

Most people in Singapore technology read Wednesday’s announcement as an appointment story and moved on. A new entity has a chief executive and a board, operations begin in early 2027, and nothing in it mentions software. I think that reading misses the only sentence in the release that will show up in engineering budgets, and it is not the one about the CEO.

What Was Announced on 28 October

The Monetary Authority of Singapore and the Association of Banks in Singapore announced the leadership team of the Singapore Payments Network, SPaN. Derek Chan is the inaugural chief executive, described in the release as bringing close to two decades of leadership experience in the payments sector, including leading payment scheme development and payments operations, work at global card schemes, and a period as Chief Business Officer of Banking Computer Services.

SPaN is governed by an 11-member board chaired by Jacqueline Loh, currently Deputy Managing Director for Corporate Development at MAS. From 1 November 2026 she becomes Principal Advisor in the Managing Director’s office while continuing as board chair. The entity is a not-for-profit set up by MAS and the Association of Banks in Singapore, and the release states it was established to consolidate the governance and development of Singapore’s national payment schemes. Fintech News Singapore and Finextra both carried the appointment the same day.

Here is the operative line: SPaN will commence operations in early 2027, with an initial focus on a smooth and stable transition of the national payment schemes from their current administrators. One caveat on scope. The specific schemes are listed in an annex to the release, which I have not read, and some secondary coverage states a particular count of schemes. I am not going to repeat a number I cannot verify against the primary document, so treat the perimeter as the schemes named in that annex rather than any figure circulating in summaries.

Why a Governance Change Lands on Engineering

Scheme administration sounds administrative. In practice the administrator of a payment scheme decides who publishes the specification, who certifies participants against it, who runs the conformance testing, and when the windows for that testing open and close. Those four things set the shape of a release calendar for every institution connected to the scheme.

When administration moves, the artefacts tend to move with it. Specifications get reissued, sometimes with clarifications that were previously informal conventions. Certification processes get restated, and a process that was a known quantity becomes a process with new paperwork and a new queue. None of that requires a technology change at all for it to consume real engineering months.

I want to be careful here, because the release does not say any of that will happen, and I am not predicting specific requirements. What I am saying is narrower and, I think, safe: consolidating governance of national payment schemes under a new entity whose stated first task is transitioning them from current administrators is the category of change that participants historically absorb through integration, testing and reconciliation work. Planning for zero is the only clearly wrong answer.

The Four Roles, and the Three Nobody Writes Down

1. Payments integration engineer

The one everybody already knows they need. The qualifier that matters is whether they have been through a scheme certification before, because certification is a scheduling and evidence discipline as much as a technical one. A candidate who has done it will talk about test windows, fixture data and the gap between passing in a sandbox and passing with a certifier watching. A candidate who has only integrated an API will talk about endpoints.

2. Message and standards engineer

Payment message formats are versioned, structured and unforgiving, and migrations between versions are where the quiet defects live. The useful screen is to ask a candidate about a field that meant one thing in an old version and something subtly different in a new one, and what they did about the records already in flight. People who have lived through a format migration have a story. People who have not will treat the question as pedantic, which is itself the answer.

3. Reconciliation and exceptions engineer

This is the role that grows fastest during any scheme change and is almost never in the requisition. During a transition the proportion of payments that do not behave exactly as expected goes up, and somebody has to build the tooling that finds them, explains them and closes them out without a person reading a spreadsheet at month end. Teams that under-hire here do not notice for two quarters, and then discover their operations headcount has grown instead.

4. Resilience engineer who can prove recovery

Availability expectations on national payment rails are unforgiving, and the distinction worth paying for is between a candidate who can describe a recovery procedure and one who has executed it against a clock. Ask when they last tested failover, what broke during the test, and what the documented procedure got wrong. An untested runbook is a hypothesis, and during a transition is a poor moment to discover which parts of yours were fiction.

What I Would Do Between Now and Early 2027

Nothing in this release asks participants to do anything yet, and there is a real risk of over-reacting to an appointment announcement. So here is the proportionate version: three pieces of work that pay for themselves whatever the transition timetable turns out to be.

Inventory your scheme touchpoints honestly. Every place your systems speak to a national payment scheme, who owns it internally, what version it speaks, and when it was last changed. Most organisations believe this document exists. Ask for it and see what arrives. Teams that cannot produce it within a week do not have one, and building it is the cheapest possible preparation.

Measure your exceptions rate before it moves. If you do not know what proportion of payments currently require manual intervention, you will not be able to tell whether a transition made it worse or whether you were always running at that level. A baseline captured now is worth more than a careful investigation later, and it costs a query.

Test one recovery procedure for real. Pick the failover you are least confident about, run it in a controlled window, and write down what the runbook got wrong. That exercise reliably produces the clearest role specification you will get, because the gaps it exposes tell you exactly which of the four profiles above you are actually missing. Our note on backend development in Singapore covers how to resource that kind of hardening work without stopping delivery.

The Timing Argument, Honestly Stated

There is a reasonable objection to everything above: no timetable has been published, so hiring against it is speculation. I accept that, and I would not build a team on an announcement.

But the asymmetry is worth naming. If you secure one experienced standards or integration engineer in the next two quarters and the transition turns out to be undemanding for your organisation, you have hired a strong payments engineer slightly early and they will have no shortage of useful work. If you wait for published specifications and the transition is demanding, you will be sourcing that person at the same moment as every other participant connected to the same rails, from the same narrow Singapore pool, with a deadline that is not yours to move. Those two outcomes are not symmetric, and that asymmetry, rather than any prediction about what SPaN will require, is the whole argument for moving early.

FAQ: SPaN and Singapore Payments Engineering Hiring