[ARCHIVE] Providing accountId in Scheduled Payments response

Archived 2022.12.11. Content moved to CDS Guide, Scheduled Payments

Question

In Scheduled Payments APIs, when there is not consent for Bank Payee Scope, the Data Holder (DH) should respond with full payee details but not with payeeId.

Does the same principle apply for Basic Account Scope?

If the Accredited Data Recipient (ADR) has only consent for Scheduled Payments Scope, should a DH provide accountId for scheduled payments between internal accounts, where accountId would apply?

Answer

The DH should respond with the accountId in accordance with the standards. The description of accountId in the BankingScheduledPaymentTo schema states that the accountId should be shared if the payment is to another account that is accessible under the current consent. If the account is not accessible under the current consent, the domestic uType and BankingDomesticPayee response must be set.

Providing accountId does not compromise the security of account information. The accountId is an opaque, non-guessable identifier field created only for the CDR,  so it can be shared. The accountId does not provide access to account information without consent. 

Withholding accountId, in this case, does not prevent an ADR obtaining an accountId by other means. For example, an ADR can use the bulk scheduled payments endpoint to get a list of accountIDs and then call the account specific version of the scheduled payments APIs.

Having an accountId does not necessarily provide access to account information. With the introduction of amending consent in the v2 Rules, an ADR could have previously obtained an account list and now no longer have access to it if consent is amended to remove the account scopes. 

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 returns an error if the Get Accounts API is called and does not return the account specific information.