The below covers notes taken from the CDR Implementation Call on the 28th of January 2021 and outlines the general approach and principles behind the Consumer Data Standards and the masking of data
The Consumer Data Right API Endpoints as specified within the Consumer Data Standards are not intended to require PCI Compliance obligations for Data Holders or Data Recipients. The presence of plain text Primary Account Number (PAN) or Credit Card numbers in the API responses will introduce this requirement and the Standards keep implementation cost and impact as primary drivers to not introduce this obligation.
As a guiding principle for implementation teams: a PAN should never be unmasked in the data provided by your organisation.
Common Field Types
The Standards provide two field types which support the masking of PAN and account numbers. These can be found as Common Field Types which include:
Tip: you can search for the above Common Field Types in the Standards to find where they are used
An example of one of these fields within the Banking APIs is under the GET Accounts endpoint. The endpoint uses the schema ResponseBankingAccountList which in turn uses the BankingAccount to define the structure for the account array. You can see the field
maskedNumber is present and requires the
MaskedAccountString Common Field Type to mask the account number.
In the same payload you can observe a field which should not have a PAN but may due to customer/ source system preferences. Observe the field
displayName which is described as "The display name of the account as defined by the bank. This should not incorporate account numbers or PANs. If it does the values should be masked according to the rules of the
MaskedAccountString common type." emphasising the approach implementation teams should work towards.
The GET Payee Details Endpoint includes a schema BankingDomesticPayee which refers to the Card Number which can be associated with the Payees registration. This field references
MaskedPANString as the Field Type to implement.
In the initial stages of the Consumer Data Standards this was defined as a string. Feedback from consultation with the community lead to the possibilities and scenarios customers could use this filed for. This included the possibility of a PAN being entered for naming or reference purposes thus the BankingBillerPayee includes
crn which is described as "If the contents of the CRN match the format of a PAN then it should be masked using the rules applicable for the MaskedPANString common type".
In the event transactions captured on an account have the PAN in the free form text fields, it is entirely appropriate to formulate a regex over these fields to mask an number matching the algorithm.
In general if the Data Holder knows there is potential for a PAN to be present they should take all reasonable steps to mask these, aligning with their relevant risk policies and procedures.
Masking in Internet Banking vs Open Banking
In some Internet Banking solutions there is no masking on the PAN. While this decision is appropriate for the organisation it does not change the requirements as part of the Consumer Data Standards. If it is defined as a Common Field Type of
MaskedAccountString then it should follow those definitions.