Other Journeys in ‘Appendices’.
OBIE Standards have been updated to allow ASPSP to provide the PISP with the following payment status information:
Payment Consent Response Status
PSU Authentication Status
Payment Initiation Response Status
Further Payment InitiationStatus
Note: In several occasions (such as in single domestic payments), the progress from payment initiation to payment processing will happen extremely quickly and the status that could be returned by the payment order submission response or subsequent call(s) to the GET status endpoint, will be any of the statuses described in items #C or #D. This may also depend on the implementation by various ASPSPs.
Payment Processing Status
Payment Execution Status
This content is best viewed on a desktop browser.
CX Considerations 2ASPSP should be able to provide the PISP with payment status information across the whole payment journey, from payment initiation, to payment processing and payment execution. This payment status information should include both high level ISO processing payment status, and also lower lever payment status information specific to the underlying payment system (for example qualified and unqualified accept for UK faster payments). PISP should use this information to determine the confidence level about the status of the payment and inform the PSU (and the receiving party if relevant) about the status of the payment.
Faster Payments is the UK’s low value near-real time payment system with deferred net settlement cycles. Faster Payments support the following payment types:
1. Single Immediate Payment (SIPs): SIPs are single payments processed synchronously by the FPS Members and the Central Infrastructure. Synchronous payments have specific SLAs for response times and thus in the majority of them the round trip time from Sender Bank sending the request till receiving the response from the Receiver Bank is usually less than 15 seconds. The receiving bank may:
a. Accept the payment: There are 2 ways the receiving can accept the incoming payment:
i. Unqualified Accept: The payment is accepted without qualification and the credit will be applied to the customer’s account within the SLA time (max 2 hours). Typically, in a lot of cases the credit is applied to the customers account within seconds. The payment is irrevocable. In the case the credit cannot be applied to the beneficiary account, the receiving bank has to initiate a Return payment providing the reason for the return. Several of the return reasons relate to the beneficiary account details not being sent correctly or the beneficiary account not being able to receive the funds
ii. Qualified Accept: The qualified accept is used cases where the receiving bank cannot guarantee that credit will be applied to the beneficiary account within the standard SLA defined by the FPS Scheme (i.e. 2 hours max). Different qualifier codes are used to indicate the timelines of the credit such as same day, next calendar day, next working day, at unspecified time and date within the PSD guidelines etc. Typical cases when qualified codes are being used are the following:
– The received payment is for an indirect member bank (agency bank). The receiving FPS settlement bank accepts the payment on behalf of the agency bank but provides a qualifier code of when the agency bank will apply the credit to the beneficiary account. Please note that while the receiving FPS settlement bank can perform some checks before accepting, they cannot check the business rules of the beneficiary account and thus the payment may still fail at the agency bank, even if it has been accepted by the receiving FPS settlement bank. In this case, the rejected payment by the agency bank also has to be returned by the FPS settlement bank.
– The received payment is for an FPS member bank but there are technical issues and the bank is not able to apply the credit to the beneficiary account within the agreed SLA.
b. Reject the payment: When receiving the payment and before responding back to the sending bank, the receiving bank will perform and number of checks in the received payment instruction. Some of these checks will include the checking of the following:
– beneficiary account sort code and number belong to the receiving bank (or sort code to one of its agencies), beneficiary account name has been provided and matches the account number
– payment details are correct in terms of currency, payment reference etc
– the beneficiary account in not stopped, closed, or transferred, the T&Cs allow the account to receive the credit and there are no beneficiary sensitivities or any other business reasons for not crediting.
If any of the above checks fail, the payment is rejected and the rejection message including the rejection reason code is sent to the sending bank. Considering that that the PISP will be initiating a payment for a known beneficiary (e.g. in case of a merchant) a lot of the above rejection codes can be avoided before the payment initiation.
Note 1: Synchronous payments are considered time critical as the expectation is that they are payments where the PSU is present initiating the payment and waiting for a result or any outcome to take place.
Note 2: Faster Payments can also be rejected by the servicing Central Infrastructure (CI). In fact, the CI continuously monitors the FPS members’ connected gateways for technical issues and availability. If member systems are unable to receive payments, the CI will reject the payments sent by the sender bank.
2. Future Dated Payments (FDPs): FDPs are single payments which are non-urgent and thus do not need to be executed immediately. They have an execution date in the future, which allows sending banks to warehouse them and process them on they day requested by the PSUs. They are being processed asynchronously by FPS member banks, which means the following:
– The sending bank is sending the payment request to the CI. The CI confirms back to the sending bank that the payment has been accepted. From the sending bank’s perspective, the payment has been successful and they can update their status accordingly.
– The CI is sending the payment request to the receiving bank. The receiving bank will perform the necessary checks and respond back to the CI if the payment is successfully accepted or not (same checks apply with SIP payments).
– If the receiving bank rejects the payment, then the CI will send a special type of return payment (called Scheme Return payment) to the sending bank. This is because for the sending bank, the payment has been successful and the PSU’s account has been debited. The Scheme Return will apply credit to the PSU’s account in order to restore the original balance prior the payment to their account.
Note: Asynchronous future dated payments are usually processed by the banks overnight on the required execution date on 365 basis (for FPS member banks). This provides a window of several hours for the payment to be processed and executed and credited to the beneficiary account before the end of the calendar day. On several bank implementations, if funds checking fails during the original attempt to process the payment, the payment will be retried again later on the same day. The cut-off point for submitting a future dated payment depends on each bank’s implementation.
3. Standing Orders (SOs): SOs are recurring payments of fixed amount to a fixed beneficiary which again are non-urgent and thus do not need to be executed immediately. They are also processed asynchronously by the FPS member banks. Thus, similarly to the FDPs, once checked by the CI, they are confirmed back to the sending bank and being considered successful. Again, if they are rejected by the receiving banks, the CI will send a Scheme Return back to the sending bank in order to return the credit back to the PSU. SOs, are being processed during week business days and the majority of them (e.g. over 90%) are expected to be processed during the FPS 1stsettlement cycle, from midnight to 6am. Finally, similarly to FDPs, on several bank implementations, if funds checking fails during the original attempt to process the payment, the payment will be retried again later on the same day. SOs scheduled for a weekend, will be processed on the first available business day of the following week.
Contingent Reimbursement Model Previous
Change Log Next
What the research says Click for customer research
What the research says