Make additional account attributes available in bulk

[JohnHarrison-Truelayer]

Description

Account number, BSB and account currency are not available in bulk with other account attributes. This can result in large wait times for consumers. For example: obtaining these details for 10 accounts would require a minimum of 12 API calls (1 to Get Accounts, 1 to Get Bulk Balances, 10 to Get Account Detail).

Area Affected

• The BankingAccount object definition
• The BankingAccountDetail object definition
• APIs supported by the standards.

Change Proposed

Add account number, BSB and account currency to BankingAccount. If some of these details are deemed sensitive then we suggest adding the remainder to BankingAccountDetail and creating a Get Bulk Account Details endpoint.

[CDR-API-Stream]

Hi @JohnHarrison-Truelayer, the account number and BSB are considered sensitive and they are currently accessible using the detailed account scope (bank:accounts.detail:read) hence why they aren't present in the basic account data API.

Currency is potentially non-binary. For term deposits there may be multiple term deposits with different maturity currencies. There is also an open consultation that was discussed in Maintenance Iteration 9 to support multiple balances and many loans (plans).

The Get Account Balance provides the currency for the account but again there may be multiple currencies provided for in the purses structure. Are you able to elaborate on what "account currency" should represent under these scenarios?

This change request in the backlog for further discussion in Maintenance Iteration 10.

[perlboy]

Reading @JohnHarrison-Truelayer's request carefully he acknowledged that BSB/Account Number might be sensitive and therefore alternatively suggested creating Get Bulk Account Details endpoint which makes a lot of sense to me and could be protected with the same bank:accounts.detail:read scope.

[CDR-API-Stream]

Hi @perlboy, as mentioned this change request is in the backlog for consideration in Maintenance Iteration 10. The consideration of a bulk account detail API was not discounted and this can be discussed with the community as part of options analysis for the change.

@JohnHarrison-Truelayer if you'd like to confirm the further considerations in this comment they can be incorporated into the discussion when for Maintenance Iteration 10 which commences this Wednesday.

[JohnHarrison-Truelayer]

The Get Account Balance provides the currency for the account but again there may be multiple currencies provided for in the purses structure. Are you able to elaborate on what "account currency" should represent under these scenarios?

We suggest that the field would have meaning consistent with the balances API. So perhaps the default currency would be an appropriate choice.

[speedyps]

This is definitely something which SISS Data Services would make use of. For the clients we support, we have already had two of them request that we build this into our middle-layer.

Our expectation would be that it falls under bank:accounts.detail:read scope, not requiring any CX changes.

Under the current model, we have to make calls to Account Details to only get the bsb, account number and currency. The remaining large set of data is just discarded.

[markverstege]

Hi @speedyps you had indicated in a maintenance iteration call that SISS Data Services also had bulk API use cases. Are you able to describe the requirements / use case for additional bulk APIs?

[CDR-API-Stream]

A Decision Proposal is required to introduce a Bulk Account Detail API, #89 DSB Item - Bulk Account Detail API has been added to DSBs future-plan backlog.

[perlboy]

Call me pedantic but doesn't the idea of creating a backlog item presuppose that the use cases which haven't yet been presented are actually validated?

[speedyps]

Hi @speedyps you had indicated in a maintenance iteration call that SISS Data Services also had bulk API use cases. Are you able to describe the requirements / use case for additional bulk APIs?

Hey @markverstege, to reduce the load on banks' APIs, we would suggest two other Bulk APIs:

1. Bulk Transaction Details. The issue SISS faces is that once we get a List of Transactions for an account (generally, the customer is not present), we need to get the Transaction Details for transactions where transactionDetail is true. Within a session, ADR systems are restricted to 100 calls, and for a customer with, say, 4 bank accounts, means we will have already made the following calls:

   • Get Accounts (to get a List of Accounts) - 1 call
   • Get Account Detail (for each Account) as we need the BSB and Account Number - 4 calls.
   • Get Bulk Balances (so one call which covers all the accounts) - 1 call
   • Get Transactions for each Account - min 4 calls

   By this point, we have made at least 10 calls. Suppose we retrieved 400 transactions (we have some clients with high transaction volume). If even a quarter of these contain detail, we need to make another 100 calls to get them. Calling this way seems an inefficient use of the APIs, especially given the limitations.
   A minor mitigation would be that our system could start another session to get the missing details. This will be a big issue for us for single-use consents, or short-term consents, where the first call would be getting historical transactions and could end up with 1000s of transactions. Even with 20 sessions (allowing 100 calls), we might not obtain all the detail.

2. Bulk Transactions (Similar to Bulk Balance calls). It would be beneficial, and potentially save a couple of calls, if we could ask for transactions for all accounts covered by the consent. Or a Bulk Transactions for Selected Accounts type call, where we specify which accounts we want transactions returned.

Another way to resolve these issues would be to add a parameter to the transaction calls to allow us to request that details be returned as part of the Transaction List.

[CDR-API-Stream]

Closing as this issue will be considered as a Decision Proposal, see comment above.