[ARCHIVE] Masking of Consumer Data Right data

Archived 2022-09-28 and contents moved to Masking guidance for CDR data.

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

General Principle

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:

• MaskedPANString
• MaskedAccountString

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.

Payees

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.

BPAY CRN

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". 

Transaction details

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 MaskedPANString or MaskedAccountString then it should follow those definitions.