How money moves on this rail, in 12 sourced records: what is final, what can be returned, recalled or refunded, who decides, and what the limits are. A profile belongs to the rulebook, so no reason code list is published on this page.
On a rail fact, every detail line names the section or instrument it rests on and whether that is a rule, a law, operator guidance, or observed practice.
A product is built on this rail and has an object of its own: an authorisation, a lifecycle or a code set. Each view below is derived by the build from records already in the corpus; see products.json for the rule.
Standing Order Payment (SOP)An asynchronous regular payment of a set amount to a named payee, held by the sending participant until the day it is due and only then submitted to the central infrastructure. Standing orders run on weekdays only, excluding public holidays in England and Wales, and a due date falling on a weekend or such a holiday is held to the next working day. A sending participant must submit at least nine in ten of its standing orders between midnight and 06:00, and must retry later in the day where the payer had insufficient funds. The payer may ask for one to be cancelled before it is submitted.5 rules, 1 authorisation, 0 states, 0 code sets; 1 draft, 6 corroboratedNot yet covered: the FPS Rules, Rules for the Faster Payments Service, and the FPS Procedures, which hold the rejection codes (Appendix B, section 8.2), the qualifier codes (Appendix B, section 7), the response time-out figures and the Credit Payment Recovery and Bank Error Recovery procedures: Pay.UK's 2025 PFMI self-assessment, key consideration 23.1, says they are available for review by participants' legal departments, and no public copy was found; the FPS Functional Specification and External Interface Specification, named in the Certainty of Fate annex, rule 10.1, and not published; the FPS standards library holding the ISO 8583 specifications and the ISO 8583 to ISO 20022 mapping, which Pay.UK says requires registration; 42 of the 50 rejection codes and 6 of the 14 return reasons a participant's developer documentation lists: only one public source family carries them, or the two families that carry them disagree, so they are held rather than drafted. The held codes are listed in docs/rails/uk-fps.md; the qualifier codes a Qualified Acceptance carries: Pay.UK publishes the five funds availability timescales they signal but no code values; the four character Confirmation of Payee reason codes, and the reason codes a sending provider records for stopping the five business day reimbursement clock, which live in the Reimbursement Claims Management System; the FPS Reimbursement Rules Compliance Monitoring Regime, the APP Fraud Reimbursement Best Practice Guide, PSR Specific Requirement 1, Specific Direction 19, the Consumer Standard of Caution Exception notice and the Compliance Data Reporting Standards, each named by a source read here and none of them opened; Bacs and the Image Clearing System, which Pay.UK also operates, are separate schemes with separate code sets and are not covered here.