Rail Catalogue Exploration

Rail Catalogue

A behavioural directory of payment rails.

Understand how payment rails actually behave in production — not just what their specifications describe.

Problem

Rail knowledge is fragmented. Rulebooks describe what is allowed, not what happens in practice.

Teams learn behaviour only after failure — when deadlines and commitments are already at risk.

Automation struggles to reason about variance. Without a clear model of how rails behave, routing logic is built on incomplete assumptions.

Concept

Determinism

Rail Catalogue focuses on determinism — how consistently a rail behaves when identical payments are sent.

Because many payment failures start with the wrong rail choice.

Determinism is not an SLA or a success rate. It describes predictability of outcome and timing — whether the same input produces a consistent class of result.

It matters at decision time: before you encode rules, choose a rail, or hand off to an agent. The more deterministic the rail, the easier it is to reason about failure modes and recovery.

Comparison

Behavioural comparison

Rail Determinism Failure timing Human intervention
SEPA SCT High Mostly pre-settlement Low
FPS Medium Mixed Medium
SWIFT CBPR+ Low Mostly post-settlement High
Takeaway

Key insight

The real question is not "which rail is best?"
It is "how much behavioural variance can I tolerate for this intent?"

Early vs late failure changes how you design retries and user communication. Post-settlement ambiguity drives reconciliation and dispute cost. Human intervention cost scales with how often outcomes diverge from what systems assume. All of this depends on understanding variance, not just capability.

What this is / what this is not

What this is

  • A neutral reference
  • Behavioural, not technical
  • Useful before encoding rules or logic

What this is not

  • Not a PSP
  • Not a routing engine
  • Not a recommendation system
  • Not an agent platform