The thesis: a named builder turns a blueprint into a treasury build item.
Nexus Global Payments, the not-for-profit company that six central banks incorporated in Singapore to run the Bank for International Settlements-originated Project Nexus, named PayNet and NETS as the Nexus Technical Operator on February 9, 2026. The joint venture, supported by Amazon Web Services and Endava, carries the mandate to build, run, and maintain the infrastructure connecting the instant payment systems of India, Malaysia, the Philippines, Singapore, and Thailand, with Indonesia participating as a special observer. Nexus Global Payments’ chief executive, Andrew McCormack, called the appointment “a major milestone towards our vision for an interoperable global payments network.” The target go-live is 2027.
That date matters less on its own than what it makes concrete. A blueprint is something a finance team reads once and files away. A named builder with a delivery target is something a treasury team can plan a project against, and the master-data and control work here does not have to wait for the rails to carry live traffic.
Four years from prototype to a named builder.
The BIS Innovation Hub’s Singapore Centre started Project Nexus in 2022 with central bank partners. A 2023 prototype linked the Eurosystem, Malaysia, and Singapore. On July 1, 2024, the project completed a comprehensive scheme and governance framework, commercial model, and technology blueprint, describing a network with the potential to connect a market of 1.7 billion people. On April 3, 2025, the five founding central banks, the Reserve Bank of India, Bank Negara Malaysia, Bangko Sentral ng Pilipinas, the Monetary Authority of Singapore, and the Bank of Thailand, incorporated Nexus Global Payments in Singapore and opened a procurement process for a Nexus Technical Operator. That process closed on February 9, 2026, with the PayNet and NETS joint venture selected from a competitive field of global bidders.
The design itself is straightforward. Rather than every domestic instant payment system building a separate bilateral connection to every other one, each system connects once to Nexus. Nexus routes the payment, converts the currency, and delivers funds to a proxy identifier, the mobile number or equivalent alias that India’s UPI, Singapore’s PayNow, Thailand’s PromptPay, Malaysia’s DuitNow, and the Philippines’ InstaPay already use to resolve domestic payments today.
Correspondent routing versus Nexus-style routing.
| Dimension | Correspondent-routed cross-border payment | Nexus-routed instant cross-border payment |
|---|---|---|
| Routing | One or more correspondent banks per corridor, negotiated bilaterally between banks | A single connection to Nexus, which routes the payment to the destination country’s own instant payment system |
| Settlement time | Same day to several business days, depending on the corridor and cutoff times | Seconds, matching the domestic instant-payment experience already live in each connected market |
| FX handling | A rate locked at initiation or applied at a correspondent bank’s own cutoff, often a day removed from settlement | A rate applied at the moment of transfer, generated and disclosed inside the same instant transaction |
| Beneficiary data required | Account number, bank identifier code, and correspondent routing details | A verified proxy identifier, such as a mobile number, resolved by the destination country’s own instant payment scheme |
| Compliance scope | One screening pass against a corridor’s established correspondent relationships | A screening pass specific to the destination country’s own sanctions and KYC regime, since each new corridor is its own compliance surface |
| Reconciliation cadence | Nightly or next-day matching against a correspondent bank statement | Near-real-time matching against a settlement confirmation that can arrive before the next accounting cutoff |
The master-data fields a Nexus-ready beneficiary record needs.
None of these fields require Nexus to be live. Each domestic scheme they describe already processes retail payment volume today, which means the master-data work is available now, not gated on a 2027 date.
Settlement corridor
Which domestic instant payment system a beneficiary’s account is linked to (UPI, DuitNow, InstaPay, PayNow, PromptPay), tracked now since every one of these schemes already processes retail volume today, independent of Nexus.
Verified proxy identifier
The mobile number or equivalent alias a destination scheme resolves payments against, captured and verified alongside the traditional account number, not instead of it.
Proxy verification date and method
When and how the alias-to-account link was confirmed, since alias resolution carries a different misdirection risk than a bank-verified account number does.
Per-transaction FX rate
A field distinct from any daily or contracted rate, ready to record the rate an instant, real-time-settled transfer actually executed at.
Corridor compliance ruleset
Which country’s sanctions and KYC regime applies to this beneficiary’s corridor, since each market connected to Nexus is its own compliance surface, not a shared cross-border bucket.
Corridor readiness status
Whether Nexus, or an existing bilateral link, currently serves this corridor, who owns tracking that status, and the source used to confirm it.
The record one corridor needs.
A structured record like the one below, held wherever treasury already tracks bank counterparty data, keeps the corridor, the proxy identifier, the compliance ruleset, and the readiness status in one place, instead of splitting them across a payments platform, a compliance spreadsheet, and a project tracker someone remembers to check.
Example beneficiary corridor record
{
"beneficiary_id": "ben-08821",
"corridor": {
"destination_country": "IN",
"domestic_scheme": "UPI"
},
"proxy_identifier": {
"type": "mobile_number",
"verified": true,
"verification_method": "micro_deposit",
"verified_on": "2026-08-01"
},
"account_number_on_file": true,
"compliance_ruleset": "IN-sanctions-kyc-2026",
"corridor_readiness": {
"route_available": "bilateral_correspondent",
"nexus_status": "build_phase_target_2027",
"last_checked": "2026-08-08"
}
}The corridor_readiness block is what keeps a 2027 go-live from becoming a surprise. It is set the day the beneficiary record is created, not the day a payment fails to route the way the team expected.
Implementation checklist.
Add a settlement-corridor field to the beneficiary and vendor master record identifying which domestic instant payment scheme a payee’s account is linked to, even before Nexus interlinks that market.
Capture a verified proxy identifier, such as a mobile number, alongside the account number for beneficiaries in these six markets, since proxy-based resolution is already how each domestic scheme routes payments.
Confirm with the treasury management or payment platform in use whether it can record the actual FX rate a real-time settlement executes at, distinct from a daily or contracted rate.
Tag each connected market in counterparty master data with its own sanctions and KYC ruleset reference, rather than a single regional bucket that treats all six the same.
Assign an owner to track Nexus Global Payments and Nexus Technical Operator milestone announcements, and update a corridor-readiness field when a market’s status changes.
Rehearse the reconciliation and FX-capture design against an existing instant or near-instant corridor already in production, so the pattern is proven before Nexus itself goes live.
Confirm with ERP, treasury management, and payment gateway vendors whether their roadmap includes Nexus connectivity, or whether each corridor will need a separate integration once it launches.
Document the beneficiary consent and verification trail behind every proxy identifier on file, since alias-based routing introduces a different fraud profile than account-number verification alone.
Start with the markets carrying the highest beneficiary count today, since those are where a proxy-identifier field pays off fastest once a corridor goes live. A market with only a handful of beneficiaries can follow once the pattern is proven.
Constructive failure modes to design around.
Waiting for the 2027 go-live before touching beneficiary master data, when the corridor and proxy-identifier fields can be added now regardless of which technical operator eventually carries the traffic.
Assuming an account-number-only beneficiary record will work unchanged once a corridor moves from correspondent banking to a proxy-alias instant rail.
Recording a daily or contracted FX rate against a transaction that actually settled at a real-time market rate seconds earlier, a small gap that compounds at volume.
Treating the six connected markets as one compliance region instead of six corridor-level sanctions and KYC rulesets, each of which applies the moment that corridor is live.
Leaving the trigger for a newly live corridor as an informal watch of industry press, rather than a tracked field in the vendor and counterparty master that someone is accountable for updating.
Each of these is a design gap the corridor, proxy-identifier, and per-transaction FX fields close directly. None of them requires new detection technology; most require adding a field to a record that already exists and assigning someone to keep it current.
What to ask treasury and payment vendors now.
Does the treasury management or payment gateway platform’s roadmap include Nexus connectivity, or would each corridor still need a separate integration once it launches?
Can the platform capture and verify a proxy identifier, such as a mobile number, alongside the traditional account number for beneficiaries in India, Malaysia, the Philippines, Singapore, and Thailand?
Does it record the FX rate a real-time settlement actually executed at, distinct from a daily or contracted rate used elsewhere in the ledger?
Can it tag a beneficiary’s compliance ruleset by destination country rather than a single cross-border category?
Who at the vendor is tracking Nexus Technical Operator and Nexus Global Payments milestones, and how quickly does that show up as a corridor-readiness update for customers?
A vendor that answers all five with documentation in hand has already built the corridor model this design calls for, which leaves only the internal beneficiary-data collection for treasury to own.
Practical takeaway.
A named technical operator and a 2027 target do not change what a treasury team owes its counterparties today. What changes is the excuse for waiting. The corridor field, the verified proxy identifier, the per-transaction FX capture, and the per-market compliance ruleset are all buildable against the domestic instant payment systems already carrying volume in these six markets, well before the first Nexus-routed transaction settles.
Sources.
- Bank for International Settlements: Project Nexus, enabling instant cross-border payments (project overview)
- Bank for International Settlements: Project Nexus completes comprehensive blueprint for connecting domestic instant payment systems globally (July 1, 2024)
- Bank of Thailand: Project Nexus partners incorporate Nexus Global Payments to run the cross-border payment scheme; search for technical operator commenced (April 3, 2025)
- Nexus Global Payments: About Nexus (founding members, incorporation, mission)
- Nexus Global Payments: Nexus Global Payments Appoints Technical Operator (February 9, 2026)
- Fintech Singapore: Nexus Global Payments Appoints PayNet and NETS to Operate Real-Time Global Platform
- Philippine News Agency: BSP, other central banks gear up for Project Nexus implementation
Targeted searches for public X and Twitter commentary on the February 2026 Nexus Technical Operator appointment returned trade-press and corporate announcement pages rather than a credible set of two to four high-signal posts from a central bank, Nexus Global Payments, or an independent practitioner. Ordinary citations are used instead, and nothing is fabricated.