[ARCHIVE] ID Permanence - Realization by the Data Holders

Archived 2023.01.11. Content moved to CDS Guide, ID Permanence

Question

The cost (and associated complexity ) of implementing ID Permanence

The following identifiers are subject to ID Permanence rules

• accountdD
• transactionId
• payeeId
• scheduledPaymentId

Let's look at the scenario described below and see what is expected here.

1 Customer - John Doe

2 Accounts - 123456789 , 987654321 (these are the actual account IDs in the core systems

Each account has 3 transactions

Account ID: 123456789

Txn001

Txn002

Txn003

Account ID: 987654321

Txn 991

Txn 992

Txn 993

2 ADRs one with 2 Software Products and other with a single Software

HonestMoneyBee - Software Products - FriendlyMoney, ConservativeMoney

TrustfulMoneyPal - Software Product - MoneyGrow

If John Doe provides consent to all three software products, the expectation from ID Permanence is as follows:

Customer	TPP	Software Product	accountId (ID Permanence)	Account ID in Back End SoRs
John Doe	HonestMoneyBee	FriendlyMoney	25f9e794323b453885f5181f1b624d0b	123456789
John Doe	HonestMoneyBee	ConservativeMoney	25f9e794323b453885f5181f1b624d0b	123456789
John Doe	TrustfulMoneyPal	MoneyGrow	9b3e61bf29f17c75572fae2e86e17809	123456789

The Data Holder is expected to keep a mapping of this value (for each account ) and translate that to the actual account numbers to fetch data from their backend Systems of Record.

The number of Account IDs held within the 'Big 4 banks' as well as the other banks would be very large. As the ecosystem grows the Data Holders must maintain this mapping info for a extended periods of time. If we have to do this for each transaction ID then the numbers are phenomenal (considering that the Data Holders are supposed to serve data for over a number of years).

How are the Big 4 and other Data Holders addressing the ID Permanence rules?

I am not sure hashing mechanism can work for ID Permanence.

A unique ID of the transaction adhering to the standards for ID permanence. This is mandatory (through hashing if necessary) unless there are specific and justifiable technical reasons why a transaction cannot be uniquely identified for a particular account type

Answer

There are a number of options to solve ID Permanence, not all include the storage of the computed values in a data store. As you correctly identify this approach is unlikely to scale in the long term. ID Permanence, itself, is not unique to the CDR and has been solved in other markets and problems.

Other examples may employ the use of shift ciphers, hashing algorithms or symmetric key encryption or a combination of these and computed storage. The solution will be dependent on the Data Holder's needs and constraints including infrastructure capacity, security requirements and so forth.

Other data holders or solution providers may be able to comment on their respective implementations.

Source

https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/210