Payments Training Hub
Authorisation: step where debtor confirms 1 Authorisation NOW 2 Such as a direct debit collection 3 Timing of the debit 4 Debit 5 Insufficient funds handling 6 Debit payment reference linkage Authorisation is the step where the debtor confirms that the payment should proceed, and the debtor agent commits the funds. Step 1 of 6 Authorisation: step where debtor confirms 1 NOW Authorisation 2 Such as a direct debit collection 3 Timing of the debit 4 Debit 5 Insufficient funds handling 6 Debit payment reference linkage Authorisation is the step where the debtor confirms that the payment should proceed, and the debtor agent commits the funds. Step 1 of 6
Such as a direct debit collection 1 Authorisation 2 Such as a direct debit collection NOW 3 Timing of the debit 4 Debit 5 Insufficient funds handling 6 Debit payment reference linkage Some payments, such as a direct debit collection, are authorised in advance through a mandate, and the authorisation at the time of collection is the mandate itself. Step 2 of 6 Such as a direct debit collection 1 Authorisation 2 NOW Such as a direct debit collection 3 Timing of the debit 4 Debit 5 Insufficient funds handling 6 Debit payment reference linkage Some payments, such as a direct debit collection, are authorised in advance through a mandate, and the authorisation at the time of collection is the mandate itself. Step 2 of 6
Timing of the debit matters 1 Authorisation 2 Such as a direct debit collection 3 Timing of the debit NOW 4 Debit 5 Insufficient funds handling 6 Debit payment reference linkage The timing of the debit matters. Step 3 of 6 Timing of the debit matters 1 Authorisation 2 Such as a direct debit collection 3 NOW Timing of the debit 4 Debit 5 Insufficient funds handling 6 Debit payment reference linkage The timing of the debit matters. Step 3 of 6
Debit must be reflected 1 Authorisation 2 Such as a direct debit collection 3 Timing of the debit 4 Debit NOW 5 Insufficient funds handling 6 Debit payment reference linkage The debit must also be reflected correctly in the customer balance, in the bank ledger, and in any liquidity reporting, because a mismatch between those views creates reconciliation breaks. Step 4 of 6 Debit must be reflected 1 Authorisation 2 Such as a direct debit collection 3 Timing of the debit 4 NOW Debit 5 Insufficient funds handling 6 Debit payment reference linkage The debit must also be reflected correctly in the customer balance, in the bank ledger, and in any liquidity reporting, because a mismatch between those views creates reconciliation breaks. Step 4 of 6
Insufficient funds handling 1 Authorisation 2 Such as a direct debit collection 3 Timing of the debit 4 Debit 5 Insufficient funds handling NOW 6 Debit payment reference linkage A payment that fails for insufficient funds may be retried automatically in some systems, or it may be rejected immediately in others. Step 5 of 6 Insufficient funds handling 1 Authorisation 2 Such as a direct debit collection 3 Timing of the debit 4 Debit 5 NOW Insufficient funds handling 6 Debit payment reference linkage A payment that fails for insufficient funds may be retried automatically in some systems, or it may be rejected immediately in others. Step 5 of 6
Debit payment reference linkage 1 Authorisation 2 Such as a direct debit collection 3 Timing of the debit 4 Debit 5 Insufficient funds handling 6 Debit payment reference linkage NOW They must also ensure that the debit and the payment instruction are linked by a unique reference, so that operations can trace a debit to its payment and vice versa. Step 6 of 6 Debit payment reference linkage 1 Authorisation 2 Such as a direct debit collection 3 Timing of the debit 4 Debit 5 Insufficient funds handling 6 NOW Debit payment reference linkage They must also ensure that the debit and the payment instruction are linked by a unique reference, so that operations can trace a debit to its payment and vice versa. Step 6 of 6

Steps of this lesson, in order.

0:00 / 1:56 Step 1 of 6

Authorisation and debit, committing the funds

Payment Lifecycle End to End, Lesson 3 of 9, Narration 1:56, D03 Payment lifecycle

ReconciliationAuthorisationSettlement

What you will learn

Your objective. By the end of this lesson, you will be able to explain authorisation and debit, committing the funds. Authorisation is the step where the debtor confirms that the payment should proceed, and the debtor agent commits the funds.

Why it matters. If the debit happens early, the customer sees the money leave quickly, but the bank must manage the funds until settlement.

Chapter objective: Learner walks a payment from initiation through validation, screening, clearing, settlement, and reconciliation, and identifies the controls and failure points at each stage of the lifecycle. Learner applies this skill in realistic banking scenarios, with clear examples and correct terminology throughout.

Key learning points

  • Authorisation: step where debtor confirms
  • Such as a direct debit collection
  • Timing of the debit matters
  • Debit must be reflected
  • Insufficient funds handling
  • Debit payment reference linkage

Key terms

Reconciliation: The process of comparing records from two sources, such as a bank statement and an internal ledger, to confirm they agree.

Authorisation: Approval by the issuer for a card transaction to proceed, confirming the card is valid and funds or credit are available.

Settlement: The final movement of funds between banks to discharge obligations created by cleared payments. Settlement is usually made in central bank money or through correspondent accounts.

Animated payment lifecycle showing Authorisation and debit, committing the funds.

Insights and practice scenarios

Worked insights and practice scenarios for this lesson. Each one is a reusable PaymentForge case, so the same case may appear in more than one lesson.

Practise this lesson

Exercise

Trace the card payment in this lesson through authorisation, clearing and settlement.

Use the four-party model and the stage timings in this lesson.

  1. What to do. State what happens at each stage, who pays whom, and when the merchant is actually credited.

Correct result. Authorisation holds the funds and returns a response code. Clearing sends the transaction in a batch file. Settlement moves the net amount between banks, and the acquirer credits the merchant after deducting interchange, scheme fees and its margin.

Why. A card payment is not one event. The customer sees it on Monday, the merchant gets it on Wednesday, and the difference is the clearing and settlement cycle.

Check your understanding

Practice question

A payment is stopped at validation because the beneficiary account number fails the format check. The customer asks the bank to send it anyway and fix the account later. What should the bank do?

Takeaway and next step

What to remember

They must also ensure that the debit and the payment instruction are linked by a unique reference, so that operations can trace a debit to its payment and vice versa.

Follow a payment through every stage, from instruction to beneficiary credit, and note where it can stop.

Open the Payment Lifecycle Simulator →

Builds on "Validation, screening and fraud checks".

Transcript and full text

Show transcript

Authorisation is the step where the debtor confirms that the payment should proceed, and the debtor agent commits the funds. In a consumer payment, authorisation may be a PIN, a biometric approval, or a one time passcode. In a corporate payment, authorisation may be a dual approval workflow where one person enters the payment and another approves it. Some payments, such as a direct debit collection, are authorised in advance through a mandate, and the authorisation at the time of collection is the mandate itself. Without proper authorisation, a payment should not proceed, because the bank would be acting without the customer mandate. Once authorised, the debtor agent debits the debtor account or places a hold on the funds. The timing of the debit matters. In some systems, the debit happens immediately on authorisation, while in others it happens at the point of clearing. If the debit happens early, the customer sees the money leave quickly, but the bank must manage the funds until settlement. If the debit happens late, the customer may spend the funds in the meantime and the payment may fail for insufficient funds. The debit must also be reflected correctly in the customer balance, in the bank ledger, and in any liquidity reporting, because a mismatch between those views creates reconciliation breaks. What can go wrong at this stage includes insufficient funds, a closed or blocked account, a limit breach, or an authorisation that has expired. A payment that fails for insufficient funds may be retried automatically in some systems, or it may be rejected immediately in others. A corporate payment that fails because the second authoriser is on leave may miss a supplier deadline. Analysts must document the authorisation model, the debit timing, the retry logic, and the customer notification for each failure. They must also ensure that the debit and the payment instruction are linked by a unique reference, so that operations can trace a debit to its payment and vice versa. Worked example with real numbers: a customer holds EUR 30,000 and instructs a EUR 28,000 supplier payment at 09:00, with a EUR 500 card authorisation hold already on the account, so the available balance is EUR 29,500. The hub checks the available balance, not the ledger balance, finds EUR 29,500 is enough for EUR 28,000, reserves EUR 28,000, and the available balance falls to EUR 1,500. At 09:05 the hub posts the booking debit of EUR 28,000, the ledger balance falls to EUR 2,000, and the pacs.008. Authorising against the available balance is therefore the control that prevents the customer from spending the same money twice. Failure and recovery: a payment authorised against the wrong balance, the ledger instead of the available, will be accepted and then fail at posting, and the customer will have been told the payment succeeded when it did not, so the recovery is to reverse the acceptance, to release the reservation, and to tell the customer the payment failed. A payment debited but never sent, because the pacs.008 creation failed, is recovered by reversing the debit with a correcting entry the same day, so the trial balance still balances. A debit with the wrong value date is corrected with a camt.087 value-date correction and a compensating interest adjustment, as taught in ch71s7. For a business analyst, product owner or subject matter expert, the test is to state, for every payment, which balance is checked, when the reservation is made, when the booking debit is posted, what the posting reference is, and what happens when the debit posts and the message fails. The ISO 20022 pacs.008 is the message, the core banking ledger is the posting, and the message identifier links the two, so the requirement must map the authorisation decision to the available balance, the debit to the ledger, and the message to the identifier. A requirement that says the account is debited, without stating which balance, when, and what the reversal rule is, will produce a payment engine that authorises payments it cannot settle. Authentication is the step that comes before authorisation, and the two controls must not be confused. Authentication proves who is instructing the payment, and authorisation proves the payment is allowed and the funds are there. A payment can pass authentication and fail authorisation, or fail authentication and never reach authorisation, and each failure has a different cause and a different fix. Authentication in full, including strong customer authentication, step-up triggers and corporate dual approval, is taught in ch4s9 Authentication: proving who you are before the money moves.

Authorisation is the step where the debtor confirms that the payment should proceed, and the debtor agent commits the funds. In a consumer payment, authorisation may be a PIN, a biometric approval, or a one time passcode. In a corporate payment, authorisation may be a dual approval workflow where one person enters the payment and another approves it. Some payments, such as a direct debit collection, are authorised in advance through a mandate, and the authorisation at the time of collection is the mandate itself. Without proper authorisation, a payment should not proceed, because the bank would be acting without the customer mandate.

Once authorised, the debtor agent debits the debtor account or places a hold on the funds. The timing of the debit matters. In some systems, the debit happens immediately on authorisation, while in others it happens at the point of clearing. If the debit happens early, the customer sees the money leave quickly, but the bank must manage the funds until settlement. If the debit happens late, the customer may spend the funds in the meantime and the payment may fail for insufficient funds. The debit must also be reflected correctly in the customer balance, in the bank ledger, and in any liquidity reporting, because a mismatch between those views creates reconciliation breaks.

What can go wrong at this stage includes insufficient funds, a closed or blocked account, a limit breach, or an authorisation that has expired. A payment that fails for insufficient funds may be retried automatically in some systems, or it may be rejected immediately in others. A corporate payment that fails because the second authoriser is on leave may miss a supplier deadline. Analysts must document the authorisation model, the debit timing, the retry logic, and the customer notification for each failure. They must also ensure that the debit and the payment instruction are linked by a unique reference, so that operations can trace a debit to its payment and vice versa.

Worked example with real numbers: a customer holds EUR 30,000 and instructs a EUR 28,000 supplier payment at 09:00, with a EUR 500 card authorisation hold already on the account, so the available balance is EUR 29,500. The hub checks the available balance, not the ledger balance, finds EUR 29,500 is enough for EUR 28,000, reserves EUR 28,000, and the available balance falls to EUR 1,500. At 09:05 the hub posts the booking debit of EUR 28,000, the ledger balance falls to EUR 2,000, and the pacs.008. Authorising against the available balance is therefore the control that prevents the customer from spending the same money twice.

Failure and recovery: a payment authorised against the wrong balance, the ledger instead of the available, will be accepted and then fail at posting, and the customer will have been told the payment succeeded when it did not, so the recovery is to reverse the acceptance, to release the reservation, and to tell the customer the payment failed. A payment debited but never sent, because the pacs.008 creation failed, is recovered by reversing the debit with a correcting entry the same day, so the trial balance still balances. A debit with the wrong value date is corrected with a camt.087 value-date correction and a compensating interest adjustment, as taught in ch71s7.

For a business analyst, product owner or subject matter expert, the test is to state, for every payment, which balance is checked, when the reservation is made, when the booking debit is posted, what the posting reference is, and what happens when the debit posts and the message fails. The ISO 20022 pacs.008 is the message, the core banking ledger is the posting, and the message identifier links the two, so the requirement must map the authorisation decision to the available balance, the debit to the ledger, and the message to the identifier. A requirement that says the account is debited, without stating which balance, when, and what the reversal rule is, will produce a payment engine that authorises payments it cannot settle.

Authentication is the step that comes before authorisation, and the two controls must not be confused. Authentication proves who is instructing the payment, and authorisation proves the payment is allowed and the funds are there. A payment can pass authentication and fail authorisation, or fail authentication and never reach authorisation, and each failure has a different cause and a different fix. Authentication in full, including strong customer authentication, step-up triggers and corporate dual approval, is taught in ch4s9 Authentication: proving who you are before the money moves.

Full lesson text (all scenes)

Completing a lesson updates your progress dashboard on the homepage.

Scene timestamps are estimated by allocating the narration text proportionally across the real audio length. The audio playback position is the source of truth: pause freezes the visual, seeking restores the correct scene, replay restarts the scene animation.