Faster payments are not the same as cost and control.

Payment rails get debated in industry forums. In day-to-day finance they show up as four questions: what does it cost, when does cash actually land, how do we reconcile it, and who owns fraud when something goes wrong? That is the frame worth using as NPP and account-to-account (A2A) access keeps evolving.

Why it matters: A2A can trim card economics and speed settlement. It can also create new exception patterns — instant outward payments that do not wait for a batch mindset, inbound references that do not match how AR expects to apply cash, and fraud that moves at rail speed while the approval matrix still assumes overnight. Controllers, AR, and recon feel the breaks first. The CFO feels them when cost-to-serve and loss events hit the pack.

Submissions into the RBA payments review around 10 September 2026 — including voices such as Airwallex, Adyen, Azupay, and the Digital Economy Council — are part of the wider conversation. You do not need to pick a side in the review to tidy your own operating model.

I'm writing for CFOs watching cost-to-serve, controllers and AR leads living in the exception queue, treasury owners of the daily cash position, and finance managers between payments ops and the board pack. Soft on providers. Hard on ownership.

Railway signals glowing above the tracks at dusk, with a gold AI scan frame labelled “AI scan · payment rails”
Faster payments vs cost and control — speed is not the operating model.

Before you widen access, do this

  1. Map all-in cost, not sticker rates. Line up every rail you use — NPP, A2A providers, card, direct entry — against scheme or provider fees, failed-payment handling, refunds, and internal touch time. Compare cost per successfully applied receipt and per successful payable.
  2. Define when “available” means available. Write the settlement definition for each rail and check whether treasury’s daily position uses the same one. Instant rails that post to the bank but lag in the ERP are a forecast problem dressed as a payments upgrade.
  3. Lock matching keys before volume grows. Decide payer identity, invoice reference, remittance advice, and how partials and overpays route. Name the exception queue owner. If A2A receipts land without a reliable reference standard, AR will invent one in a spreadsheet — and you will pay for that inventiveness every month.
  4. Spell out fraud and liability ownership. Who can initiate, who dual-authorises, what velocity limits apply, how recalls and disputes work on each rail, and who is on the hook when a push payment goes to the wrong account. Faster rails need faster kill-switches — tested, not theoretical.
  5. Fill a one-page ownership map. Rail → fee owner → settlement definition → recon owner → fraud owner → escalation. If any cell is blank, you are not ready for scale.

Sequencing that stays pro-foundation

You do not have to rip out what works. Pilot A2A where remittance quality is high and exception volumes are measurable. Keep human approval on new payee setup and high-value outs. Widen only when recon break rates and fraud metrics stay inside limits you’d show a board risk committee.

AR and recon should see the pilot metrics weekly — break rate, time-to-apply, false positives on fraud flags — not a monthly slide. If those numbers aren’t owned, the CFO will hear about A2A as a cost win while the finance team absorbs silent rework.

Evaluate providers on fee transparency, settlement clarity, recon tooling, and liability language — not on who shouted loudest in a review process.

Payments reform often gets framed as access and speed. In practice it is decision design: know true cost-to-serve, own settlement definitions, keep recon and fraud ownership named, and expand only when the break rates would survive a risk committee.

Full checklist stays on FinanceSignal.ai — peer notes for finance people who have to live with the call.