Orca

New Payments Platform (Australia) ยท a product on this rail

Mandate Payment (PayTo)

A product on New Payments Platform (Australia), derived by the build from 18 rules, 3 authorisations, 5 states and 0 code sets that already exist in the corpus. Nothing here is hand-written.

Rail au-npp, governed by NPP Australia Limited. Snapshot 2026-09-20, built 2026-09-26, commit 019924ac64ee0aa0742b8f02a04488a83633385d. Data: data/products/au-npp/mandate-payment.json.

What it is

Corroborated (authoritative primary) The name and summary are the TransactionType record's own, with its own status. This product is derived by the build from 33 records that already exist (1 draft, 32 corroborated; strongest source class authoritative primary), and the page carries no status, confidence or corroboration of its own.

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.

Anchor
3 authorisations of its own, a lifecycle of its own (5 states)
Effective since
Unknown: the Regulations date individual amendments, not the provision as a whole
Confidence
medium
Record
au-npp:txn.mandate-payment

Who can use it

  • Connected Institution institution; bound by its rules
  • Initiating Participant institution; bound by its rules
  • MPS User party; receives the authorisation, bound by its rules
  • NPP Australia Limited (NPPA) operator; bound by its rules
  • Overlay Service Provider service_provider; bound by its rules
  • Payer Customer party; gives the authorisation, bound by its rules
  • Payer Participant institution; receives the authorisation, bound by its rules
  • Payment Initiator service_provider; bound by its rules
  • Sponsor institution; bound by its rules

How it is authorised

Authorised Payment Mandate (a PayTo agreement) Corroborated (authoritative primary)

The ordinary PayTo mandate. It is a record of a payment authorisation the payer gives in favour of a business or a payment initiator, and the record does not live with either of them: it lives in the Mandate Management Service, a central access controlled database the scheme operator runs, under a unique identifier the database itself generates. It gives the holder the right to send requests instructing the payer's own institution to make payments inside the mandate's terms, and it is only active once the payer's institution has recorded in the database that the payer authorised it. Three parties act and an operator holds the record, which is the thing that makes it unlike every other mandate in the corpus.

Form
A record in the Mandate Management Service, the scheme operator's own central database, identified by a mandate identifier the database generates. It is not a document either party keeps. The payer authorises it in their own institution's channel after that institution delivers the authorisation request to them in near real time, and the institution then records the confirmation in the database. Lookup rights belong to the parties to the mandate and the information in the record is confidential to them.
Scope
  • a stated amount, purpose and frequency the payer authorised, which the record itself is the evidence of. No amount is typed as a constraint because no source gives a figure: what the sources give is the shape of the range, and three of the reason codes the authority publishes sit at its edges, one for an amount below the minimum the agreement allows, one for an amount that is not the amount agreed or expected, and one for an amount above a limit the payer and their own bank agreed
  • one off, ad hoc or recurring payments to the business or provider named in it
  • payments the payer's own institution makes as ordinary credit pushes; nothing is pulled
  • active only while the payer's institution has recorded the payer's authorisation in the operator's database
Recurrence
The mandate states the frequency the payer authorised, and the record in the operator's database is the evidence of it. The rulebook sets no ceiling of its own on the number of payments and no public document gives one.
Counterparties
The mandate names the business or payment initiator it is given to, and where a beneficiary is recorded the record is the evidence of that too. A payment initiator's mandate may be moved to a different participant or connected institution on the initiator's instruction without the authorisation changing.
Given by
Payer Customer
Given to
MPS User The authorisation runs to the business or payment initiator, but the record is held by the scheme operator and the authorisation is validated and recorded by the payer's own institution. One target uid cannot carry all three positions; the operator's custody is in form and in the rules this mandate is governed by.
Governed by
A PayTo mandate is a record in a database the scheme operator runs, not a document a party keeps; Offering PayTo is optional for a creditor's bank and compulsory for the payer's bank; The payer's institution must deliver the authorisation request to the payer in near real time; No payment request may be sent unless the mandate is active; A change to the amount or the frequency has to come from the business as a fresh agreement; A mandate may be moved to another institution without the authorisation changing; A mandate record is confidential to its parties and may be looked up only by them; A claim about an ordinary mandate is tested against the record, or against evidence the initiator must produce
Cancelled through
The payer's institution must give the payer a way to view, suspend, cancel and amend their mandates
Evidenced by
The mandate record is the evidence of the amount, the frequency and the beneficiary
Disputed through
Mandate claim shared with the rail
Record
au-npp:mandate.authorised-payment-mandate

Debtor Payment Arrangement Draft, unchecked

The third thing the Mandate Management Service can hold, and the thinnest. A payer's own institution may choose to store records of these arrangements in the database, and it is answerable for payments made in connection with them. What one is, who gives it and to whom, and how it is authorised, amended or ended are all defined in the procedures rather than in the published rulebook, so Orca can say that the record type exists and almost nothing else.

Form
Not held. The published rulebook defines this term only by pointing at the NPP Procedures Volume 6, which is available to members and direct affiliates only and was not consulted. What is known is that storing these in the operator's database is optional for the payer's institution and that the institution is responsible for payments made in connection with them.
Scope
  • not held: the arrangement's scope is defined in a document Orca cannot read
Given by
Payer Customer [Inference] from the term itself and from the payer participant being the party that stores the record. No read source says who gives one.
Given to
Payer Participant [Inference] the payer's own institution is the party that opts to store the record and is responsible for the payments. No read source names a holder.
Governed by
A PayTo mandate is a record in a database the scheme operator runs, not a document a party keeps
Record
au-npp:mandate.debtor-payment-arrangement

Migrated DDR Mandate Corroborated (authoritative primary)

A PayTo mandate created out of an existing direct debit arrangement, and the one mandate in the corpus that nobody consented to. The business and its sponsoring participant create it in the operator's database unilaterally, and it is deemed active the moment it is created, with no authorisation step and no message to the payer's institution asking for one. Its safeguards are notice and delay rather than consent, and its risk shows up in the claim rules, where the burden of proof falls on the sponsor rather than on the payer.

Form
A record the business's sponsoring participant creates in the Mandate Management Service from an existing direct debit request, mapped across as the procedures prescribe, and deemed active on creation. The payer never authorises it. The payer's own institution may choose to satisfy itself that the record matches its customer's existing direct debit and may ask the customer to confirm, but it is not obliged to, and pending any word from the customer it must keep processing requests against the record.
Scope
  • an existing direct debit arrangement and nothing else; one of these cannot be created from scratch
  • deemed active on creation, with no payer authorisation step
  • unusable for a payment initiation request until 5 days after it was created
  • conditional on the business having given the payer written notice, as its direct debit service agreement requires or at least 14 days beforehand
  • conditional on direct debit processing of the same arrangement stopping from the migration date, except in a genuine outage
Execution window
No public document gives a date on which this kind of mandate stops being creatable. The date recorded here is not an execution window of the mandate but the earliest date the whole of the part that governs it was in force; the industry target for retiring the direct debit system these mandates come from is 2030, which would end them, and that target rests on a source not read here [Unverified].
Recurrence
The terms are the terms of the direct debit arrangement the record was mapped from, not terms the payer gave the operator's database. That is why a claim about one is tested against the original direct debit authorisation.
Counterparties
The business is the direct debit user the participant already sponsored, deemed approved as a user of the service by the act of creating the record, and its BECS user identifier must be carried in the record so the payer's institution can check the arrangement against its own customer's history.
Given by
Payer Customer Only in the sense that the payer once authorised the direct debit this record was mapped from. No authorisation was given for this record, and the rulebook does not pretend otherwise.
Given to
MPS User
Governed by
A migrated direct debit mandate is created unilaterally and is active the moment it exists; A migrated mandate needs written notice to the payer first, at least 14 days ahead; A migrated mandate may not be used for a payment request until 5 days after it was created; Until the payer says something, their institution must keep processing a migrated mandate; A claim about a migrated mandate is deemed substantiated unless the sponsor produces the evidence; No payment request may be sent unless the mandate is active; A mandate record is confidential to its parties and may be looked up only by them
Cancelled through
The payer's institution must give the payer a way to view, suspend, cancel and amend their mandates
Evidenced by
The mandate record is the evidence of the amount, the frequency and the beneficiary
Disputed through
Mandate claim shared with the rail
Record
au-npp:mandate.migrated-ddr-mandate

States Orca holds

  1. PayTo agreement: created, awaiting the payer's authorisation Corroborated (authoritative primary)

    The business's sponsor has created the agreement record in the Mandate Management Service, and the payer has not yet said yes or no. The operator's database has sent an authorisation request to the payer's institution, which must match it to the payer by account number and put it in front of them in near real time; no payment may be requested under it yet. A migrated direct debit mandate never passes through this state, because it is active from the moment it is created.

    Money moved: no. Then: PayTo agreement: active; PayTo agreement: declined by the payer. au-npp:state.mandate-awaiting-authorisation

  2. PayTo agreement: declined by the payer Corroborated (authoritative primary)

    The payer was shown the agreement and refused it, and their institution recorded the refusal in the Mandate Management Service. The agreement never became active and no payment may be requested under it. If the terms were wrong, the business has to create a fresh agreement for the payer to authorise.

    Terminal. Money moved: no. au-npp:state.mandate-declined

  3. PayTo agreement: active Corroborated (authoritative primary)

    The payer's institution has recorded in the Mandate Management Service that the payer authorised the agreement, or the agreement is a migrated direct debit mandate, which the rulebook treats as active from creation. Only now may the business's side send payment initiation requests, and each must fit the agreement's terms. A change of amount or frequency comes from the business as an updated agreement for the payer to authorise again; the payer may pause or cancel it from their online banking.

    Visible as: MMS mandate status Active, the name the NPP Regulations give it. Money moved: no. Then: PayTo agreement: suspended (paused); PayTo agreement: cancelled. au-npp:state.mandate-active

  4. PayTo agreement: suspended (paused) Corroborated (authoritative primary)

    The agreement has been put on hold, most often by the payer through their institution's online banking, where it is called pausing. While it is suspended no payment may be requested under it, and a payment procured anyway counts as unauthorised for a Mandate Claim. It can be made active again, and the operator's overview says only the party that paused it can do that. Pausing leaves the payer's contract with the business untouched.

    Visible as: shown to the payer as paused in their online banking (AP+ FAQs and the PayTo Service Overview); the Regulations' word is Suspend. Money moved: no. Then: PayTo agreement: active; PayTo agreement: cancelled. au-npp:state.mandate-suspended

  5. PayTo agreement: cancelled Corroborated (authoritative primary)

    The agreement has been ended, by the payer through their institution or by the side that is permitted to under its terms. It can never again carry a payment request, and a payment procured under it after cancellation counts as unauthorised for a Mandate Claim. The record stays in the operator's database for investigations. Cancelling ends the authorisation, not the payer's contract with the business.

    Terminal. Money moved: no. au-npp:state.mandate-cancelled

The states listed are the ones Orca holds for this product, in the order their own records give; a state the corpus does not hold is a gap, not an absence.

Its own codes

  • AG01 Transaction forbidden Corroborated (authoritative primary) au-npp-reject:AG01
  • AM06 Too low amount Corroborated (authoritative primary) au-npp-reject:AM06
  • AM09 Wrong amount Corroborated (authoritative primary) au-npp-reject:AM09
  • AM21 Limit exceeded Corroborated (authoritative primary) au-npp-reject:AM21
  • MD01 No mandate Corroborated (authoritative primary) au-npp-reject:MD01
  • NAUT Not authorised Corroborated (authoritative primary) au-npp-reject:NAUT

Timings and limits

RuleParameterAs typed on the record
A migrated mandate may not be used for a payment request until 5 days after it was created Corroborated (authoritative primary)time window5 days from the time and date the migrated mandate record was created, before it may be used for a payment request. The rulebook says five days without saying calendar or business days, and calendar days is Orca's reading [Inference].
A migrated mandate needs written notice to the payer first, at least 14 days ahead Corroborated (authoritative primary)time windowAt least 14 days before the migrated mandate record is created, or whatever longer notice the direct debit service agreement requires. The rulebook says fourteen days; it does not say whether they are calendar or business days, and calendar days is Orca's reading [Inference].

Its rules, by facet

18 Rules, each in its record's own words with its own status. A rule reached only through the authorisation says so; a rule that also applies to another transaction type names it.

Finality 1

The paying institution cannot cancel or recall a payment once the message is in its own gateway Corroborated (authoritative primary)

The point of no return on this rail is early and it is inside the sending institution. Once the clearing request has been input into the payer participant's own gateway, that participant may neither cancel it nor recall it. Nothing later moves that point, and there is no message in the scheme for taking a payment back.

Rests on rule. Confidence medium. Also applies to Basic Single Credit Transfer (BSCT), Overlay Service Payment (OS Payment). au-npp:rule.finality-no-cancel-or-recall-once-the-message-is-in-the-gateway

Messages 2

A rejected mandate payment initiation request must also carry a valid and applicable reason code Corroborated (authoritative primary)

The same shape on the PayTo leg. A payer participant must respond to each mandate payment initiation request inside the timeframes the procedures prescribe with a status report indicating receipt and either acceptance or rejection, and where it rejects it must provide a valid and applicable reason code. Where it accepts and funds are available it then sends a clearing request for the amount claimed. Again no value is listed.

Rests on rule. Confidence medium. au-npp:rule.messages-a-rejected-mandate-payment-request-carries-a-reason-code

The platform has used ISO 20022 natively since launch Corroborated (authoritative primary)

Every message on this rail is an ISO 20022 message and always has been. A clearing request that starts a payment is a pacs.008, the clearing notification that answers it and the settlement notification the settlement service sends are both pacs.002, the settlement request is a pacs.009, a return is a pacs.004 and a request for one is a camt.056. On the customer to institution leg a payment instruction is a pain.001, a creditor payment initiation request under PayTo is a pain.013, and the status report back to a corporate customer is a pain.002.

Rests on rule. Confidence medium. Also applies to Basic Single Credit Transfer (BSCT). au-npp:rule.messages-iso-20022-from-launch

No facet on the record 15

A PayTo mandate is a record in a database the scheme operator runs, not a document a party keeps Corroborated (authoritative primary)

The Mandate Management Service is a centralised, secure, access controlled database of mandates that the scheme operator established and runs. A mandate is a record in it of a payment authorisation the payer gave in favour of a business or a payment initiator, identified by a unique mandate identifier the database itself generates, which gives the holder the right to send requests instructing the payer's own institution to make payments within the mandate's terms. The database may also hold, at the payer institution's option, records of another kind of arrangement defined only in the procedures.

Rests on rule. Confidence medium. au-npp:rule.mandate-a-mandate-is-a-record-in-the-scheme-operators-database

A mandate may be moved to another institution without the authorisation changing Corroborated (authoritative primary)

A mandate can change custodian. The payer's institution must facilitate porting a mandate where necessary at the payer's request, and a mandate established for a payment initiator may be moved to another participant or connected institution on the initiator's instruction. An institution's right to read a mandate record is expressly subject to the other parties' right to port it away. All the porting provisions took effect on 5 May 2023.

Rests on rule. Confidence medium. Reached through the authorisation, not linked to the transaction type directly. au-npp:rule.mandate-a-mandate-may-be-ported-to-another-participant

A claim about a migrated mandate is deemed substantiated unless the sponsor produces the evidence Corroborated (authoritative primary)

This is where the missing consent shows up. Where a mandate claim relates to a migrated mandate, the claim is deemed to be substantiated unless the sponsoring participant produces written evidence both of the payer's authorisation of the direct debit request the mandate was based on and that the payment in question was authorised by the mandate's terms. The burden runs against the side that created the record without asking.

Rests on rule. Confidence medium. Reached through the authorisation, not linked to the transaction type directly. au-npp:rule.mandate-a-migrated-mandate-claim-is-deemed-substantiated

No payment request may be sent unless the mandate is active Corroborated (authoritative primary)

A participant or connected institution acting as the initiating participant must not send a mandate payment initiation request unless the associated mandate is active, and is responsible for each request it sends being properly built and consistent with the mandate's terms. Sending one against a suspended or cancelled mandate is one of the things the rulebook lists as not authorised, which is what turns the resulting payment into a claim. The payer's institution may look the mandate up before processing but is not obliged to.

Rests on rule. Confidence medium. au-npp:rule.mandate-a-request-may-not-be-sent-unless-the-mandate-is-active

A change to the amount or the frequency has to come from the business as a fresh agreement Corroborated (public primary)

A payer can pause, resume and cancel, and can make the amendments the mandate's terms permit, but cannot simply raise or lower what they agreed to. The operator's parent says that for a change of amount or frequency the business has to make the change and send the payer an updated agreement to authorise. That keeps every change to the substance of the authorisation on the same footing as the original one.

Rests on guidance. Confidence medium. Reached through the authorisation, not linked to the transaction type directly. au-npp:rule.mandate-an-amount-or-frequency-change-comes-from-the-business

A claim about an ordinary mandate is tested against the record, or against evidence the initiator must produce Corroborated (authoritative primary)

For an ordinary PayTo mandate the rulebook splits the claim in two. Where the payer's institution says the payment was not permitted by the mandate in amount, frequency or beneficiary, the claim is deemed substantiated by reference to the record in the operator's database itself, which is what makes that record the evidence. Where it says the payer did not authorise that particular payment at the time the request was sent, the claim is deemed substantiated unless the initiating side produces evidence that they did, and if the two of them disagree about the reliability of that evidence they may use the rulebook's own dispute resolution process.

Rests on rule. Confidence medium. Reached through the authorisation, not linked to the transaction type directly. au-npp:rule.mandate-an-authorised-mandate-claim-is-deemed-substantiated-by-the-record

The payer's institution must deliver the authorisation request to the payer in near real time Corroborated (authoritative primary)

Creating a mandate record is not the same as authorising it. The payer's institution must be able to receive authorisation requests from the operator's database, must associate each one with a payer by the account number in the record, must deliver it to that customer in near real time for authorisation to the standards the procedures set, must take any consents privacy law needs, and must record the confirmation in the database promptly after the customer authorises or rejects it. The mandate is active only once that confirmation is recorded.

Rests on rule. Confidence medium. Reached through the authorisation, not linked to the transaction type directly. au-npp:rule.mandate-authorisation-is-delivered-in-near-real-time

A mandate record is confidential to its parties and may be looked up only by them Corroborated (authoritative primary)

Lookup rights are restricted to the parties to the mandate, and information in a mandate record must be treated as confidential to them and not disclosed to anybody else except as law requires. A lookup may be performed only for validating and processing requests and payments, resolving investigations and claims, fraud investigation and analytics, or giving effect to the parties' own instructions. Institutions must have systems to prevent unauthorised disclosure, to spot it promptly when it happens, and must tell the operator in writing when it does.

Rests on rule. Confidence medium. Reached through the authorisation, not linked to the transaction type directly. au-npp:rule.mandate-data-is-confidential-to-the-parties

A migrated mandate may not be used for a payment request until 5 days after it was created Corroborated (authoritative primary)

The second safeguard is delay. A migrated mandate may be used to issue a mandate payment initiation request no earlier than five days after the time and date it was created. To let the payer's institution check the arrangement against its own customer's account status and transaction history, the record must carry the business's direct debit user identifier.

Rests on rule. Confidence medium. au-npp:rule.mandate-five-days-before-a-migrated-mandate-may-be-used

A migrated mandate needs written notice to the payer first, at least 14 days ahead Corroborated (authoritative primary)

The consent step is replaced by a notice step. Before the record is created, the business must have told each of its payers in writing that future debits will generally go through the platform rather than the direct debit system where their account can take them, and must have given whatever notice its direct debit service agreement requires or at least fourteen days. It must hold and be able to produce evidence of the original direct debit authorisation and of the notice. Direct debit processing of the same arrangement must stop from the migration date, except in a genuine outage. The operator's parent tells customers they may opt out during the notice period and stay on direct debit.

Rests on rule. Confidence medium. Reached through the authorisation, not linked to the transaction type directly. au-npp:rule.mandate-fourteen-days-notice-before-a-migrated-mandate-is-created

Offering PayTo is optional for a creditor's bank and compulsory for the payer's bank Corroborated (authoritative primary)

The service is asymmetric by design. Taking part is optional for a participant acting as a provider of the service to businesses, optional for a connected institution, and optional for an overlay service provider, but it is mandatory for every participant and sponsored institution in its capacity as a payer participant and account servicer. A payer's institution must also provide the service for every account type that is enabled and eligible to make payments on the platform.

Rests on rule. Confidence medium. Reached through the authorisation, not linked to the transaction type directly. au-npp:rule.mandate-participation-is-mandatory-for-a-payer-participant

The payer's institution must give the payer a way to view, suspend, cancel and amend their mandates Corroborated (authoritative primary)

A payer participant must provide a facility that lets payers see the mandates they are a party to and give instructions to suspend or cancel them or make permitted amendments to them, and must promptly give effect to those instructions. Whoever performs any mandate maintenance function is responsible for making sure the particular mandate's terms allow it. The operator's parent describes the same thing to customers as pausing, resuming or cancelling in online banking, and says that doing so does not change the customer's contract with the business.

Rests on rule. Confidence medium. Reached through the authorisation, not linked to the transaction type directly. au-npp:rule.mandate-the-payer-customer-can-view-suspend-cancel-and-amend

Until the payer says something, their institution must keep processing a migrated mandate Corroborated (authoritative primary)

The payer's institution could optionally satisfy itself that a migrated mandate really matches its customer's existing direct debit and may ask the customer to confirm it, and must keep a record if the customer does. If the customer says authorisation was never given, or tells it to suspend or cancel, it must act promptly. But pending confirmation or any other instruction from the customer, it must continue to process payment requests against the mandate. Treating one of these as unauthorised by default would misstate the rule as badly as treating it as authorised.

Rests on rule. Confidence medium. Reached through the authorisation, not linked to the transaction type directly. au-npp:rule.mandate-the-payer-participant-keeps-processing-pending-word

The mandate record is the evidence of the amount, the frequency and the beneficiary Corroborated (authoritative primary)

The rulebook says out loud what most rails leave implicit: the mandate record is evidence of the quantum, the frequency and, where it is recorded, the beneficiary of the payments the payer authorised. That single sentence is why a claim that a payment fell outside the amount, frequency or beneficiary of an ordinary PayTo mandate is deemed substantiated simply by reference to the record.

Rests on rule. Confidence medium. Reached through the authorisation, not linked to the transaction type directly. au-npp:rule.mandate-the-record-is-evidence-of-quantum-frequency-and-beneficiary

What it inherits from the rail

  • Settlement How and when does the money settle between institutions?

    No rule specific to this product is held for this question. The rail's own answer is linked; whether it applies to this product unchanged is not asserted. How and when does an NPP payment settle?.

  • Hours When does the rail run, and what are its cut-offs?

    No rule specific to this product is held for this question. The rail's own answer is linked; whether it applies to this product unchanged is not asserted. When is the NPP open?.

  • Limits What limits apply to a payment, and who sets them?

    No rule specific to this product is held for this question. The rail's own answer is linked; whether it applies to this product unchanged is not asserted. Is there a limit on an NPP payment?.

  • Return How does a payment come back, and on what deadline?

    No rule specific to this product is held for this question. The rail's own answer is linked; whether it applies to this product unchanged is not asserted. How does money come back on the NPP?.

  • Recall Can the sender ask for a payment back, and who decides?

    No rule specific to this product is held for this question. The rail's own answer is linked; whether it applies to this product unchanged is not asserted. Can an NPP payment be recalled?.

  • Refund Can the payer get the money back, and on what right?

    No rule specific to this product is held for this question. The rail's own answer is linked; whether it applies to this product unchanged is not asserted. Can a customer get an NPP payment refunded?.

  • Liability Who bears a loss when something goes wrong?

    No rule specific to this product is held for this question. The rail's own answer is linked; whether it applies to this product unchanged is not asserted. Who bears the loss on an NPP payment?.

  • Consumer law What does the law give a consumer here, beyond the rulebook?

    No rule specific to this product is held for this question. The rail's own answer is linked; whether it applies to this product unchanged is not asserted. What consumer law sits above the NPP?.

  • Participants Who may take part, and in what role?

    No rule specific to this product is held for this question. The rail's own answer is linked; whether it applies to this product unchanged is not asserted. Who takes part in the NPP?.

  • Human decision points Where does a rule leave the decision to a bank or a person?

    No rule specific to this product is held for this question. The rail's own answer is linked; whether it applies to this product unchanged is not asserted. Where does somebody decide something on the NPP?.

Where the rail's answer differs for it

Shared with the rail

  • Mandate claim shared with the rail

    The rail's own exception; this product's records point at it and it is not restated here. Reached from au-npp:mandate.authorised-payment-mandate (disputed via), au-npp:mandate.migrated-ddr-mandate (disputed via), au-npp:rule.mandate-a-request-may-not-be-sent-unless-the-mandate-is-active (part of), au-npp:rule.mandate-an-authorised-mandate-claim-is-deemed-substantiated-by-the-record (part of), au-npp:rule.mandate-the-record-is-evidence-of-quantum-frequency-and-beneficiary (part of), au-npp:rule.mandate-a-migrated-mandate-claim-is-deemed-substantiated (part of).

  • Settlement rejection, which voids a cleared payment shared with the rail

    The rail's own exception; this product's records point at it and it is not restated here. Reached from au-npp:rule.finality-no-cancel-or-recall-once-the-message-is-in-the-gateway (part of).