Versions Compared

Key

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

alert-icon-red-11.pngImage Added

 

ATTENTION:

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

https://github.com/frmscoe/docs/blob/main/Knowledge-Articles/01-Knowledge-Articles/18-Entity-Resolution-Explained.md

This page will no longer be maintained in Confluence.

Table of Contents

What is it?

Entity resolution is a process of data disambiguation, which is a fancy way of saying that we want to identify a unique entity out of the sum of available data. To understand entity resolution, we must first define what we mean by an “entity”.

...

The table below lists the data fields available in the Mojaloop messages that could be used to support an entity resolution process for the payer or payee in a transaction.

Field Name

Description

POST /quotes

PUT /quotes

POST /transfers

PUT /transfers

Comments

payee

Information about the Payee in the proposed financial transaction.

Y

 

 

 

This field and sub-fields define a container structure for information about the payee

payee.partyIdInfo

Party Id type, id, sub ID or type, and FSP Id.

Y

 

 

 

This group of fields define a container structure for information about the payee. The set of information aims to uniquely identify a payee within the payee DFSP network. The Mojaloop API provides for a number of different ID Types (MSISDN, EMAIL, PERSONAL_ID, etc) but it is important to note that this information is intended to assist the eco-system in identifying the account, and not necessarily the account-holder. In all uses, this information is assumed to be unique within the context of a DFSP, and with possible intrinsic meaning only to that DFSP.

Where the partyIdType is PERSONAL_ID, the partySubIdOrType field contains additional descriptors for the identification information (e.g. PASSPORT, NATIONAL_ID_CARD, etc).

Depending on which ID Types are in use, this information is essential in resolving the identity of the payee, or at the very least the payee account information.

It is also possible, given the way that the Account Lookup Service (ALS) functions, that the same account may be identified through vastly different sets of partyIdType information, e.g. an MSISDN vs an EMAIL may resolve to the same payee account. This decision and information is not transparent even to Mojaloop - a DFSP will confirm that the target payee can be reached on the DFSP network using the credentials provided, but nothing more.

This information is initially supplied by the Payer in the POST /quotes message to specify the destination (Payee) of the transaction.

While a payee may be identified by a number of different attributes, the Mojaloop API only provides for the specification of a single attribute per transaction, which complicates the entity resolution process somewhat. If additional information is deemed essential to the entity resolution process, it would have to be provided in the extension list.

{OPEN QUESTION} What happens if a DFSP has multiple facilities for the same payee?

payee.partyIdInfo.partyIdType

The type of the identifier.

Y

 

 

 

payee.partyIdInfo.partyIdentifier

An identifier for the Party.

Y

 

 

 

payee.partyIdInfo.partySubIdOrType

A sub-identifier or sub-type for the Party.

Y

 

 

 

payee.partyIdInfo.fspId

The FSP identifier.

Y

 

Y

 

This field defines the DFSP that says that it can reach an account that is linked to the partyIdInfo information provided. The DFSP provides necessary context for the identity of the payee and is essential in entity resolution.

payee.partyIdInfo.extensionList

Optional list of extensions to the payee information, specific to deployment.

Y

 

 

 

While this data structure information does not explicitly contain information that identifies the payee entity, additional information may be provided in the extension list for this purpose. The range of additional information is defined by the scheme rules under which a Mojaloop switch operates.

payee.partyIdInfo.extensionList.extension

An optional extension element defined by a key-value pair

Y

 

 

 

payee.partyIdInfo.extensionList.extension.key

The key for an optional extension element value

Y

 

 

 

payee.partyIdInfo.extensionList.extension.value

The value for an optional extension element key

Y

 

 

 

payee.name

The name of the party, could be a real name or a nick name.

Y

 

 

 

This information has limited utility since it is largely scheme-specific. It is as likely that this field will contain an alias to describe the account as it is to have the name of the payee; however since the use of this field may be prescribed by the Mojaloop implementation scheme rules, it may be used to contain information useful for entity resolution.

{OPEN QUESTION} Which of the 4 messages contains this information?

payee.personalInfo

Personal information used to verify identity of Party such as first, middle, last name and date of birth.

Y

 

 

 

This field and sub-fields define a container structure for personal information about the payee.

payee.personalInfo.complexName

First, middle and last name.

Y

 

 

 

This group of fields is expected to contain the name of the payee and is essential in resolving the identity of the payee.

{OPEN QUESTION} Which of the 4 messages contains this information?

payee.personalInfo.complexName.firstName

First name

Y

 

 

 

payee.personalInfo.complexName.middleName

Middle name

Y

 

 

 

payee.personalInfo.complexName.lastName

Last name

Y

 

 

 

payee.personalInfo.dateOfBirth

Date of birth

Y

 

 

 

The date of birth is an essential additional component to resolve the identity of a person.

{OPEN QUESTION} Which of the 4 messages contains this information?

payer

Information about the Payer in the proposed financial transaction.

Y

 

 

 

This field and sub-fields define a container structure for information about the payer

payer.partyIdInfo

Party Id type, id, sub ID or type, and FSP Id.

Y

 

 

 

This group of fields define a container structure for information about the payer. The set of information aims to uniquely identify a payer within the payer DFSP network. The Mojaloop API provides for a number of different ID Types (MSISDN, EMAIL, PERSONAL_ID, etc) but it is important to note that this information is intended to assist the eco-system in identifying the account, and not necessarily the account-holder. In all uses, this information is assumed to be unique within the context of a DFSP, and with possible intrinsic meaning only to that DFSP.

Where the partyIdType is PERSONAL_ID, the partySubIdOrType field contains additional descriptors for the identification information (e.g. PASSPORT, NATIONAL_ID_CARD, etc).

Depending on which ID Types are in use, this information is essential in resolving the identity of the payer, or at the very least the payer account information.

It is expected that the payer that is associated with a DFSP is usually identified in a standardised way from one transaction to the next by that payer’s DFSP, based on the DFSP’s preferred identification method, as well as, possibly, scheme rule directives; however it is also possible, given the way that the Account Lookup Service (ALS) functions, that the payer’s account may be identified through different sets of partyIdType information when the payer becomes a payee.

While a payer may be identified by a number of different attributes, the Mojaloop API only provides for the specification of a single attribute per transaction, which complicates the entity resolution process somewhat. If additional information is deemed essential to the entity resolution process, it would have to be provided in the extension list.

payer.partyIdInfo.partyIdType

The type of the identifier.

Y

 

 

 

payer.partyIdInfo.partyIdentifier

An identifier for the Party.

Y

 

 

 

payer.partyIdInfo.partySubIdOrType

A sub-identifier or sub-type for the Party.

Y

 

 

 

payer.partyIdInfo.fspId

The FSP identifier.

Y

 

Y

 

This field defines the DFSP that hosts the account of the payer identified by the partyIdInfo information provided. The DFSP provides necessary context for the identity of the payee and is essential in entity resolution.

payer.partyIdInfo.extensionList

Optional list of extensions to the payer information, specific to deployment.

Y

 

 

 

While this data structure information does not explicitly contain information that identifies the payee entity, additional information may be provided in the extension list for this purpose. The range of additional information is defined by the scheme rules under which a Mojaloop switch operates.

payer.partyIdInfo.extensionList.extension

An optional extension element defined by a key-value pair

Y

 

 

 

payer.partyIdInfo.extensionList.extension.key

The key for an optional extension element value

Y

 

 

 

payer.partyIdInfo.extensionList.extension.value

The value for an optional extension element key

Y

 

 

 

payer.name

The name of the party, could be a real name or a nick name.

Y

 

 

 

This information has limited utility since it is largely scheme-specific. It is as likely that this field will contain an alias to describe the account as it is to have the name of the payer; however since the use of this field may be prescribed by the Mojaloop implementation scheme rules, it may be used to contain information useful for entity resolution.

This information is expected in the POST /quotes message.

payer.personalInfo

Personal information used to verify identity of Party such as first, middle, last name and date of birth.

Y

 

 

 

This field and sub-fields define a container structure for personal information about the payer

payer.personalInfo.complexName

First, middle and last name.

Y

 

 

 

This group of fields is expected to contain the name of the payer and is essential in resolving the identity of the payer.

payer.personalInfo.complexName.firstName

First name

Y

 

 

 

payer.personalInfo.complexName.middleName

Middle name

Y

 

 

 

payer.personalInfo.complexName.lastName

Last name

Y

 

 

 

payer.personalInfo.dateOfBirth

Date of birth

Y

 

 

 

The date of birth is an essential additional component to resolve the identity of a person.

geoCode

Longitude and Latitude of the initiating Party. Can be used to detect fraud.

Y

Y

 

 

While this information does not necessarily resolve to a specific address that is related to a person, this location information can be used to differentiate between two persons who share significant ambiguous attributes between them. For example, a person who (usually or exclusively) transacts from one town or country, as opposed to a person with similar information who transacts from another town or country.

This information is to be used to resolve an ambiguous profile via inspection by a user, and not as part of the automated entity resolution process due to a higher level of inference.

geoCode.latitude

The Latitude of the service initiating Party.

Y

Y

 

 

geoCode.longitude

The Longitude of the service initiating Party.

Y

Y

 

 

Ref: ISO20022 and Actio | Mojaloop to ISO 20022 mapping

...

Consider the following scenarios related to the kind of information captured in the partyIdInfo structure:

  1. MSISDN: An MSISDN is a mobile phone number. The number is often used in Mobile Money contexts as the identifier for the facility where monetary value is stored (i.e. an 'account'). An average person may have the same mobile number for many years; however people who use this number for nefarious ends typically change their number often and as soon as the number is compromised. In poorer environments, people may also share a number within a family, or within a community. Over a longer time-frame, numbers may also be recycled by an operator and may not currently be connected to the same person that previously used the number. As such, an MSISDN is considered a secondary and unreliable identifier, with low to high volatility, for entity resolution purposes.

  2. EMAIL: An email address can also be used to identify a customer profile and account within many systems. Consider where a customer uses their email address to log into a platform. Even beyond that, an email address may be an attribute of the customer profile that could be used to look up the profile. Email addresses are generally expected to belong to a single person and it is tempting to use the email address as an identifier for a person. Using an Email address as a unique identifier is challenged by the fact that a person may have multiple email addresses and could have full control over the issuing of their own email addresses. Public email providers will allow the creation of any number of email addresses and even a single email address may be reachable by an alias extension as part of the email specification (e.g. name+1@email.com will reach the same destination as name@email.com). Email addresses can be abandoned or cancelled at any time. On certain platforms, abandoned or cancelled email addresses may even be recycled. As such, an email address is considered a secondary and unreliable identifier, with low to high volatility, for entity resolution purposes.

  3. PERSONAL_ID: In general, a personal identification number is the holy grail as a trusted and unique identifier for the customer’s identity. In theory, numbers issued by a specific issuing authority is supposed to be unique, though identity theft and poor process control in issuing or verifying/validating information pose challenges in the effectiveness of certain types of personal identification. As mentioned previously, without the additional information regarding the specific issuing authority, the personal identifying information provided in the Mojaloop message is insufficient to guarantee uniqueness. Regardless, a personal identifier, with varying degrees of trust determined by the issuer, is considered a primary and reliable identifier, with extremely low volatility, for entity resolution purposes.

One additional over-arching challenge in Mojaloop’s implementation of the partyIdInfo structure is that any given transaction only provides a single means of identification at a time. The message cannot natively provide an MSISDN and a PERSONAL_ID. Also, consecutive transactions from or to the same person may provide different values for partyIdInfo, even from the same DFSP. In one transaction, it may be an MSISDN. In another, it may be an email address. In yet another, it may be a personal ID of some kind.

...