Versions Compared

Old Version 2

changes.mady.by.user Johan Foley

Saved on

compared with

New Version Current

changes.mady.by.user Laurence Reeve

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

 

ATTENTION:

This page has been migrated to the Tazama GitHub repository and is now located at:

https://github.com/frmscoe/docs/blob/dev/Knowledge-Articles/Entity-Resolution/Entity-Resolution-Specification-for-Implementation.md

This page will no longer be maintained in Confluence.

Table of Contents

Entity resolution

Objective:

To determine if the debtor (or creditor) in a transaction is the same person that had transacted previously, even if from a different account.

Pre-requisites

  1. Account information from previous transactions have been independently pseudonymised and stored in the Account Lookup Table and includes:

a.       DFSP ID

b.       Account ID Type

...

The account pseudonym can be used to reference the account without exposing the underlying information

  1. The Date of Birth information has not (yet) been pseudonymised and is exposed in the following messages:

a.       pain.001 – e.g. CstmrCdtTrfInitn.PmtInf.Dbtr.Id.PrvtId.DtAndPlcOfBirth.BirthDt

...

d.       pacs.002 does not contain any date of birth information

  1. The name information in the ISO 20022 message is a concatenated field that contains the first name, middle name and last name of the debtor. The name information has not (yet) been pseudonymised. The components of these values are stored in the Supplementary Data envelope in the following messages (and only for messages sourced through Mojaloop and the PPA; messages sourced from elsewhere will need an alternative solution, if possible, or utilise the concatenated value.):

a.  pain.001 – e.g. CstmrCdtTrfInitn.PmtInf.CdtTrfTxInf.SplmtryData.Envlp.Doc.Dbtr.FrstNm

...

d.  pacs.002 does not contain any name information

  1. There is no address information available (by default) in the ISO message for a Mojaloop implementation, though the Mojaloop extension list could be utilised to host this information. ISO 20022 provides for address information in its structure, but has not been implemented as such for the MVP.

  2. There is no citizenship, residency, or place of birth information available (by default) in the ISO message for a Mojaloop implementation, though the Mojaloop extension list could be utilised to host this information. ISO 20022 provides for citizenship, residency and place of birth information in its structure, but has not been implemented as such for the MVP.

...

Process steps

  1. Retrieve all pain.001 transactions from the historical transaction data where the Date of Birth for either the debtor or the creditor matches the Date of Birth for the subject in the current (incoming) transaction

a. It is assumed that the information will not change from pain.001 through to pacs.008 and therefore only pain.001 will be evaluated. If we are evaluating changes to the data from one message to another, that should be either the subject of a typology (data manipulation) or a data quality assurance process (post-MVP).

  1. Check the history for an exact match.

a.       Evaluate each record retrieved in step 1.

  1. Match incoming debtor against historical debtor

a.       Check if the First Name, Middle Name and Last Name of the debtor in the incoming transaction exactly matches the First Name, Middle Name and Last Name of the debtor in the transaction history record

  1. If an exact match is found, add the Actio Entity Identifier from the debtor in the historical record to the debtor in the incoming record, as follows:

a.       The current Mojaloop identifier for the debtor is presented in the ISO 20022 pain.001 (and pain.013 and pacs.008) JSON message in the following structure:      

...

d.       Once the element has been added, set the value of Othr[1].Id in the incoming message to the value for Othr[x].Id in the historical transaction where SchmeNm.Prtry = "ACTIO_EID".

  1. Log the discovery of the match and then stop further entity resolution for the debtor.

  2. If the debtor information in the historical record does not match the debtor information in the incoming record, check the creditor information in the historical transaction

a.       Check if the First Name, Middle Name and Last Name of the debtor in the incoming transaction exactly matches the First Name, Middle Name and Last Name of the creditor in the transaction history record

  1. If an exact match is found, add the Actio Entity Identifier from the creditor in the historical record to the debtor in the incoming record (see step 4 above).

  2. Log the discovery of the match and then stop further entity resolution for the debtor.

  3. If an exact match has not been found among the debtors and creditors in the transaction history, the program must check for a suitable fuzzy match instead against each of the transactions in the transaction history result in step 1.

a.       ACTIO must provide for a configurable threshold to limit the range of a fuzzy match.

...