Closed jsaxon-red closed 1 year ago
The DSB recommends option 1 and updating the description of the isTokenised
flag as follows:
This would help clarify that the isTokenised
can be used in scenarios where the account details (bsb and account number) cannot be shared due to being held in a closed system and is not shared via any other channels.
Feedback on the proposal is welcome.
Biza.io supports the proposal to adopt Option 1 of modifying the description.
This issue has been staged and can be viewed here - https://github.com/ConsumerDataStandardsAustralia/standards-staging/pull/281/commits/b3e10da4f532aaa994c83d1d74275cdbd2c70fb6
Description
Under the Energy 'Get Agreed Payment Schedule' API where a consumer has a Direct Debit configured the Data Holder is required to provide the BSB and Account Number, unless the Data Holder stores this information in a Tokenised form, in which case these details are not provided and a 'isTokenised' boolean flag is set to 'True' instead.
This presents an undesired technical implementation quirk where a Data Holder stores these details in a secured but untokenised way, the Data Holder needs to choose between a material relaxing of the secured storage of the details to make these available or an implementation of Tokenisation. If the latter option is chosen then once the details are Tokenised, they are no longer required to be provided.
Area Affected
/energy/accounts/{accountId}/payment-schedule
Change Proposed
Whilst there may be other viable options, two readily identified options suggested are:
DSB Proposed Solution
The DSB proposed solution for this issue is in https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/591#issuecomment-1567730366