Scheduled payments classification
When initiated by the Data Holder (DH) on the customer's behalf, a regular payment such as a loan repayment can be considered as a scheduled payment by the DH.
The Data Standards Body (DSB) does not expect historic scheduled payments to be returned by the DH, only active and ongoing payments for an account that have been scheduled. However, it is at the discretion of the DH on how to represent these items.
BpayViewBill is a facility provided by BPAY to view all the bills together on a single internet page. The classification of auto-payments made using this facility is entirely at the discretion of the biller or the DH. If treated as scheduled payments, then they must be provided through the Scheduled Payments API, according to the CDS.
From a DH perspective, scheduled payments can be classed as forward-dated payments that are supposed to debit the account at some point in the future. When responding to a Get Scheduled Payments For Account request only active and ongoing payments scheduled by the DH should be included.
A single-time future-dated payment can be considered a scheduled payment. The recurrence union in the scheduled payment structure has a onceOff variant specifically designed to accommodate this scenario.
Periodic credit card payments are not considered direct debits. If the schedule is managed by the DH then they may be considered scheduled payments.
Staged payments are not scheduled payments
The Scheduled Payments endpoint is not designed to cover bulk payments registered for execution. The bulk format is a set of 'staged' complex payment instructions. The Standards do not cover staged, filed based, bulk payments and these do not need to be shown in the Scheduled Payments endpoint.
Scheduled payment fields clarifications
TheintervalSchedule
field is meant to capture the schedule of payments intervals or the recurrence of payment frequency such as weekly, fortnightly, monthly, quarterly and yearly.
The lastWeekDay
object includes both the interval and the last week day to apply. Interval is defined as an array to allow the flexibility of having multiple intervals occurring simultaneously dayInInterval
field is used to specify a specific day in an interval for the payment. For instance, a payment that always occurs on the 10th of the month would have an interval of P1M
and a dayInInterval
of 10.
For a joint account, if a scheduled payment is to be made to an account in the consumer's payees address book and the consumer has consented to sharing payee data, then the value of toUType should be payeeId. This payeeId is the linking reference to the payee record that the ADR could call using the Get Payee Detail API.
If a payee in a scheduled payment has the same BSB and account number as a registered payee in the customer's IB address book and if the CDR solution is able to perform the match to a known payee, then it is appropriate to set the toUType field to payeeId. Where there is no matching saved payee, it is appropriate to set the toUType field to domestic.
Scheduled payment API
The DH response to Get Scheduled Payment requests is not expected to contain any back-office sweeping arrangements. It is designed to represent specific payments set up by the user.
In Scheduled Payments APIs, when there is no consent for Bank Payee Scope, the DH should respond with full payee details but not with payeeId.
If the ADR has only consent for Scheduled Payments Scope, then a DH should provide accountId
for scheduled payments between internal accounts, where accountId
would apply.
If the ADR does not have the consumer's consent to access the account data (for example, bank:accounts.basic:read privilege) then the DH should return an error if the Get Accounts API is called and does not return the account specific information.
Provided the ADR has the accountId
, it can request Schedule Payments using a consent that has only bank:regular_payments:read scope. This situation may occur when an ADR has previously collected the account data under an amended consent. In the case of concurrent consent, the ADR may have established one consent with the account scopes and another with the scheduled payment scope.
If a customer has not consented with bank:payees:read scope, the customer's payeeId
cannot be provided. In this case, the Get Scheduled Payments for Account response contains the payment set that uses one of the accountId
, domestic
, biller
or international
payee
representations.
Comments
0 comments
Please sign in to leave a comment.