Quick read. Moving money is not one operation. A payment passes through identities, messages, decision points, network links, queues, ledgers and settlement rules. Mathematics helps by representing the system as a graph of nodes and edges, a sequence of states, and a set of constrained optimisation problems involving time, liquidity, cost and reliability.

This article is a public educational model of payment-system mathematics. It does not describe private bank routing logic, security controls or operational instructions for bypassing payment systems.

The one-sentence answer

A payment system moves a value instruction from an identified sender to an identified receiver through a permitted network path, while managing message order, liquidity, failure recovery and the moment at which settlement becomes final.

Why this belongs in mathematics education

Payment infrastructure combines graph theory, queueing, optimisation, probability, functions, accounting identities and algorithms. It is also a clear example of how mathematics leaves the page and becomes infrastructure: the answer must not merely be numerically correct; it must arrive at the right destination, in the right state, without being applied twice.

Singapore provides a useful public example. The Association of Banks in Singapore states that PayNow lets customers transfer Singapore-dollar funds using proxies such as a mobile number, NRIC/FIN, UEN or Virtual Payment Address, and that the transfer itself moves through FAST. FAST is an interbank electronic funds-transfer service designed for near-immediate Singapore-dollar transfers between participating institutions.

1. Separate addressing from movement

A common conceptual mistake is to treat the identifier typed by a sender as the route itself. In a proxy-based system, the visible identifier can first be resolved to an account relationship. The payment instruction then travels across a payment rail.

This resembles the distinction between a name and a network address in computing. One layer answers “Who is the intended receiver?” Another answers “How does the instruction get there?” Keeping those layers separate makes the model easier to audit.

2. A payment network can be drawn as a graph

Represent participating institutions or system components as nodes. Represent allowed communication or settlement relationships as edges. A payment route is then a path through the graph.

Node: an institution, service or ledger endpoint.
Edge: an allowed transfer or messaging relationship.
Weight: a quantity such as cost, expected delay or risk used in an educational routing model.
Path: a sequence of edges connecting source to destination.

A shortest-path algorithm can illustrate route selection, but real payment systems are not simply public maps on which every transaction independently chooses the mathematically shortest route. Legal, technical, scheme and settlement rules constrain which paths exist. The graph is a teaching abstraction.

3. Routing is a constrained optimisation problem

If several valid routes exist, an educational objective function might combine cost c, expected delay d and a reliability penalty q:

RouteScore = alpha c + beta d + gamma q

The weights alpha, beta and gamma express priorities. But optimisation is only meaningful after feasibility constraints are applied. A cheap path that is unavailable, non-compliant or unable to settle the required currency is not a valid candidate.

4. Payment systems are state machines

A transaction should not be treated as a single Boolean “paid/not paid.” It can move through states such as received, validated, authorised, queued, submitted, accepted, settled, rejected, reversed or expired. The exact states differ by system, but the state-machine concept is general.

A transition has preconditions. For example, a payment cannot validly move from “received” to “settled” merely because a user interface displayed success. The system needs the required downstream event or confirmation.

5. Why idempotency matters

Networks fail. A sender may not receive a response and may retry. Without protection, a retry can create a duplicate transfer. The computational property called idempotency means that repeating the same logical request does not create a second unintended effect.

In a simplified design, a unique transaction identity can let the receiver recognise that a request has already been processed. The deeper mathematical lesson is that “message delivered twice” and “economic action applied twice” must not be treated as the same event.

6. Queues appear when payments cannot all settle immediately

When a system receives more instructions than can immediately be processed or when a participant lacks sufficient available settlement liquidity at that instant, payment instructions may wait. Queueing theory asks how arrival rates, service rates and priorities affect waiting time and congestion.

A basic queue has an arrival rate lambda and service rate mu. If work arrives faster than it can be served for a sustained period, the queue grows. In real financial infrastructure, the “service constraint” can include processing capacity, liquidity and scheme rules rather than only computer speed.

7. Real-time gross settlement changes the liquidity problem

In a real-time gross settlement system, eligible payments are settled individually in central bank money rather than waiting for a later batch netting cycle. The European Central Bank explains that T2 settles payment orders one by one on a continuous basis with immediate finality and provides liquidity-management and optimisation features.

The benefit is strong settlement finality and reduced exposure to another participant’s failure between trade and settlement. The trade-off is that participants must manage intraday liquidity carefully.

8. Netting reduces required movement but changes timing

Suppose Bank A owes Bank B $100 and Bank B owes Bank A $80. Gross settlement would move $180 in two directions. Bilateral netting could reduce the net obligation to $20 from A to B, subject to the rules of the system.

With many participants, multilateral netting can reduce total settlement amounts further. But netting introduces dependencies: the final net position depends on a set of obligations being considered together. The algorithm is no longer simply “settle each item immediately.”

9. Liquidity-saving mechanisms are optimisation algorithms

Imagine A is waiting to pay B, B is waiting to pay C, and C is waiting to pay A. Each payment might appear blocked if considered alone, yet the set may be solvable together if the system can identify offsetting flows. Optimisation procedures can search for combinations of queued payments that can settle simultaneously under available liquidity and priority constraints.

This is closely related to flow problems in graph theory. The network matters because one node’s outgoing payment can become another node’s incoming liquidity.

10. Priorities prevent one queue from becoming one undifferentiated line

Some payment systems allow priority rules or liquidity reservations. Mathematically, this creates a scheduling problem. If every payment is first-in-first-out, an early large payment can potentially delay many later smaller ones. If priority is unconstrained, low-priority work can starve. The scheduler therefore needs explicit policy.

11. Settlement and messaging are different layers

A payment message tells systems what is intended. Settlement changes ledger positions according to the scheme’s rules. Messaging success does not automatically prove settlement success. Keeping these layers separate is essential for error diagnosis.

Modern payment infrastructures increasingly use structured messaging standards such as ISO 20022. Better structured messages can improve interoperability and data quality, but a richer message does not remove the need for settlement logic.

12. Reliability is a probability problem

If a route depends on several components in series, overall availability can be lower than the availability of any single component. In a simplified independent-components model, if three required components each have availability 0.999, the path availability is approximately:

0.999 × 0.999 × 0.999 ≈ 0.997

Redundant paths can improve resilience, but only if failover itself works and does not create inconsistent state. Reliability engineering therefore joins probability with state management.

13. Failure recovery needs a reconciliation equation

After an outage or ambiguous response, each system should be able to reconcile what it believes happened. A simple invariant for a closed ledger is that total debits and credits across the relevant entries balance according to the accounting rules. At the transaction level, identifiers, timestamps and state histories help distinguish “never processed,” “processed but response lost,” and “processed twice.”

14. A useful Singapore example: PayNow over FAST

According to the Association of Banks in Singapore, PayNow allows a sender to use a proxy such as a mobile number or UEN rather than entering the recipient’s bank and account number, while the underlying interbank transfer moves through FAST. That gives students a clean layered picture:

Identity/proxy layer: resolve the recipient.
Instruction layer: create the transfer request.
Rail: move the interbank payment through the participating infrastructure.
Bank ledgers: reflect the resulting debit and credit according to system rules.
Confirmation layer: communicate outcome to users and institutions.

This is a conceptual decomposition, not a claim about every internal implementation detail.

15. Cross-border payments make the graph deeper

Cross-border transfers can introduce additional institutions, currencies, compliance steps, time zones and settlement systems. The path may include correspondent relationships rather than one domestic rail. Each added hop can add cost, delay and failure modes.

That is why “send money from A to B” is not one universal algorithm. It is a family of routing and settlement problems under different network constraints.

16. Diagnostics for a payment-routing model

Can every accepted payment be traced through a valid state sequence?
Can a retry create a duplicate economic effect?
Does every route terminate at an eligible receiver?
Are currency and settlement constraints checked before routing?
Does queue length rise persistently under current load?
Are high-priority payments causing starvation elsewhere?
Can queued payments be released when incoming liquidity changes the network state?
Can the system reconcile after a partial outage?
Are messaging success and settlement success reported separately?

17. Falsifiers: observations that reveal a bad model

The model predicts “settled” from a user-interface acknowledgement alone.
A retry can generate two transfers with no duplicate detection.
A routing optimisation selects paths that are not legally or technically feasible.
Queue simulations assume infinite liquidity.
Availability calculations assume component independence when failures share a common cause.
A cross-border path is modelled as though it were one domestic bank-to-bank edge.

18. Connection to school mathematics

Graphs: routes, nodes, edges and paths.
Sequences: transaction state changes over time.
Rates: arrivals and service in queues.
Probability: component reliability and failure.
Optimisation: cost, delay, liquidity and priorities.
Algebra: conservation and balancing relationships.

This is the kind of transition from classroom mathematics to real infrastructure explored in Bukit Timah Tutor’s public Career Mathematics | The Engineer Series.

19. Update triggers

A payment-system model should be revisited when participants change, message standards change, routing rules change, new rails are introduced, settlement arrangements change, capacity changes, resilience architecture changes or observed queue and failure behaviour departs materially from the model.

Sources and further reading

Final idea. A payment is not a number flying through the internet. It is a stateful instruction moving through a constrained network. Graphs tell us where it can go, queues tell us when it can move, optimisation tells us which feasible action is preferable, and reconciliation tells us whether the economic result actually happened.

Small Group Tutorials

How Payment Systems Move Money: Graphs, Queues, Routing and Real-Time Settlement