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.
Mandate Payment (PayTo)A payment the payer's own institution makes on the strength of an active mandate held in the Mandate Management Service, after an initiating participant sends it a mandate payment initiation request. Nothing is pulled: this is an ordinary credit push that a stored authorisation set going, which is why the rulebook calls it a persistently authorised debit-like credit transfer.18 rules, 3 authorisations, 5 states, 0 code sets; 1 draft, 32 corroboratedOne other transaction type holds rules on this rail but no authorisation, lifecycle or code set of their own, so each is a transaction type and not a product: Basic Single Credit Transfer (BSCT) (8 rules).
Not yet covered: the current edition of the governing rulebook. NPPA publishes NPP Product Rules v.31 of September 2026 openly, and all 102 pages are scanned images with no text layer and no extractable character, so every record here rests on the previous readable edition, NPP Regulations v21.0 of 24 September 2024, and what moved between the two is not held; the NPP Product Procedures, which are available to members and direct affiliates only under AP+ Scheme Rule 1.2(e). They hold the interbank reason code values, every response timeout, every return and acknowledgement window, the mandate indemnity settlement periods, the Mandate Authorisation Standards, the Confirmation of Payee rules and the definition of a Debtor Payment Arrangement; the interbank reason code values a rejected Clearing Request and a rejected Mandate Payment Initiation Request must carry. Regulation 6.3(a)(ii) and Regulation 17.8(b)(i) require a valid and applicable reason code and neither lists a value; mandate status reason code values, which no public AP+ document lists; Confirmation of Payee reason code values, which live in NPP Procedures Volume 12 and on the developer portal; every NPP timeout, return window and service availability target. Each is a configurable value or a target prescribed in the Procedures, and no public figure exists for any of them; the AP+ developer portal documentation, whose robots.txt disallows the documentation path and which requires an account; which institutions subscribe to the ePayments Code. The Code binds subscribers only and ASIC's subscriber list was not opened; whether a Clearing Participant, a Connected Institution or an Identified Institution can be named. Nothing public distinguishes them; the RBA's RITS membership list identifies Fast Settlement Service participants only; BECS, BPAY and eftpos, which are separate schemes under the same parent and would need their own briefs.