This article is intended to be read by people responsible for integration of National Registration System (NRS) with FIFA Connect ID Service. It discusses the concept of the international duplicate comparison and resolution. It explains why NRS needs to have/build such a functionality and shows some examples to use as an inspiration. 

Make sure that before proceeding you have read this article.


TABLE OF CONTENTS

Introduction

One of the most important benefits that an MA gets out of integration with FIFA Connect ID Service is international duplicate detection. This functionality allows MA to know that the person they are trying to register is likely to have already played for another MA. For this benefit to be realised, however, NRS needs to have the functionality of displaying the details of potential duplicates and comparing them with the records they are trying to register.

We are assuming you have read this article and you already know that:

  • FIFA Connect ID Service does not store personal data but it has information that a certain person is registered in a certain MA
  • when the human operator tries to register a person in NRS which is integrated with Connect ID, the service checks for duplicates and for each potential duplicate it sends a request for person details to a respective MA. Note that there may be multiple potential duplicates from multiple MAs.
  • at the end of this process, NRS contains detailed data about potential duplicates from other MAs.

In order for the user (operator of the NRS) to complete the registration process, they need to see this detailed information and be able to compare it with the data of the person they have tried to register. Depending on the result of this comparison, they might need to:

  • continue registration of the person (force register) if they turn out not to be a duplicate
  • adopt the FIFA_ID of another person if they turn out to be the same and add a registration (e.g. if we learned that a person is a football player in France we might still want them to become a beach soccer referee in Spain)
  • or even start a transfer process (e.g. if we learned that a person is a football player in another MA and we want to register them as a football player as well).

Refer to this article to see the diagrams describing the business process to be implemented here.


Although we can't tell you exactly how to implement international duplicate comparison, we can provide some inspiration. We strongly recommend that you build your UI in a way that allows displaying all the information that is available (both general information from Connect ID and detailed information from other MAs), including the person's photo.


You should avoid at all costs adding your inactive registration to an existing FIFA_ID! Since Connect ID is not storing the history of registrations, such an operation will replace the current registration of another MA with your historical registration. If you want to assign an existing FIFA_ID to your historical record, without overwriting data centrally, use the data holders functionality instead.




The following is our recommendation for what new screens might be needed to efficiently handle potential duplicates resolution. Please adapt this recommendation to the specifics of your NRS.


Screen 1 - the list of records that haven't been registered

It is important that MA has an easy way to see how many records do not have FIFA_ID and why. The largest group will of course be 409 "errors" meaning that potential duplicates have been found for a given record. It can therefore also be considered as a task list for the registration department, listing all players/ persons with potential duplicates in FIFA Connect ID, so that those can be resolved and the person/ player can be assigned a FIFA ID. Occasionally there might be other, non-business errors for which usually the best action is to retry the registration.

This functionality/screen will be important:

  • just after the initial import of data where the number of potential duplicates is the highest and special process needs to be applied to solve all of them efficiently
  • during the normal operations, if a potential duplicate is found for a person that is being registered

Since after the initial "bulk" assignment of FIFA IDs to existing players this list can be long, it makes sense to introduce filters for the registration department so that they can work on different batches according to priorities

  • by player with potential international vs national duplicates (players with international duplicates would have higher priority)
  • by level of the registered player: amateur vs. pro (pro would have higher priority)
  • if you assign FIFA IDs to different roles, by role: player vs match official vs team official (players would have higher priority than other roles)
  • by registration status of the person: active vs inactive (active would have higher priority)
  • by registration date

Screen 2 - list of potential duplicates for a particular record / potential duplicates overview

From the list discussed in the previous paragraph, user should be able to enter the context of a single record. Within this context an overview of all potential duplicates could be displayed along with some general information about each. This would allow the operator to pick the most probable duplicate even before checking the details. 


Since March 2023, each potential duplicate returned includes information about the date of the registration in Connect ID. This can be used for cases when more than two potential duplicates are returned. More on the topic can be found in the following articles:
Merging: how to decide which record is primary?
What to do if two or more records come up as potential duplicates?



Screen 3 - details of potential duplicates for a particular record / comparison

This screen should show all the details of a potential duplicate. The usual implementation presents this as a window with two records: the record being registered (without a FIFA_ID yet) on the left and potentially duplicated record on the right. More advanced implementations help the operator by visually marking all the difference e.g. in name and date of birth.


Examples


Example 1

This video shows how the provider of one of the NRS-es implemented a duplicate resolution screen in their system. It's worth to watch the whole process but the duplicate comparison screen doesn't appear until 2 minutes into the video (link to exact moment).


Example 2

See the two screens below with a bit of description.


Screen 2 - potential duplicates overview

This screen shows basic information about a person being registered (top row). The table rows are potential duplicates - all the information apart from the "Name" in this table comes from FIFA Connect ID Service. This information contains too few details for the operator to be able to decide whether something is or is not a duplicate. User clicks "Resolve" button to see details of the potential duplicate and take an action.






Screen 3 - potential duplicate details

In this screen we can see all the personal data (including the photo) that we got from another MA (in this case England). This should be enough information to be able to decide whether a true duplicate has been found or just a false positive.

Example 3

Three screens from Connect Platform test system.


Screen 1 - list of records without a FIFA_ID



Screen 2 - potential duplicates overview


Appears after user has clicked "View" on the previous screen.


Screen 3 - potential duplicate details


Appears after user has clicked "View and compare" on the previous screen.

Understanding person details message

Note that the XML message does not directly correspond with what is shown in the screen above. In one case you will need to do additional processing. We are talking about PlayerRegistration/OrganisationFIFAId attribute. It may contain two different values:

  • FIFA_ID of the Club that the player is/was registered in (preferred case)
  • FIFA_ID of the Member Association that the player is/was registered in

In both cases, you will need to translate FIFA_ID into the Club/MA name. You can achieve this by using GetOrganisation() method of our SDK and passing OrganisationFIFAId value as a parameter. The object returned will contain the information you require to display the name and to determine the type of organisation (internationalName, organisationNature). For more details refer to chapter 4.2 Getting organisation data of the SDK documentation.


Understanding general information coming from Connect ID

In most cases, it won't be necessary but if you want to understand the meaning of fields returned by Connect ID (not by the MA as this has been covered above), i.e. score, queriedHash, queriedDateOfBirth, matchedHash and matchedDateOfBirth, refer to this article.


Multiple potential duplicates vs multiple versions of the same potential duplicate

A single person may hold a couple of different registrations in different MAs. For example, one can be a Football Player in Germany, while being a Futsal Coach in Poland at the same time. In rare cases it may happen that such a person [with multiple registrations] will be found as a potential duplicate of the record you are trying to register. Please note that in such a case:

  • only one MA will be asked for person details (not both/all of them). The reason behind this system's behaviour is to avoid a potential confusion by an operator who would receive multiple, potentially different, versions of the same person. The goal here was also to simplify the UI for the duplicate resolution.
  • person details arriving from a single MA will contain only the registrations history for this particular MA - this may be a bit misleading if this person is active in multiple MAs.
  • however, the record coming from the Connect ID Service, will still contain all the current registrations from all MAs along with some basic information. From this it follows, that your system needs to be able to display both:
    • the list of current registrations as sent by the Connect ID Service
    • the list of historical registrations in a given MA that was sent by that MA as part of the person details


Let's take a look at the following example. The example was simplified to make the point clear:

  • you try to register "Jon Smith" in your NRS
  • two potential duplicates arrive from the Connect ID Service
    • FIFA_ID: ABC, Active Football Player Amateur in Germany AND Active Futsal Coach in Poland
    • FIFA_ID: DEF, Active Football Player Pro in France
  • two requests for details are automatically sent by the system (without you having to do anything) and the following information is returned:
    • FIFA_ID: ABC, Active Football Player Amateur in Germany AND Active Futsal Coach in Poland
      • "John Smith", score 0.9
      • Borrusia Dortmund from 2011 to 2013
      • Bayern Munich from 2014 to ...
    • FIFA_ID: DEF, Active Football Player Pro France
      • "Jon Smit", score 0.85
      • Paris Saint-Germaine from 2018 to ...


As you see, there is no information coming from Poland although one of the persons (ABC) is an active coach there. This is not a problem, however, because Germany returned detailed information about player ABC already.


What if the other MA does not respond and there are no personal details available?

On rare occasions, another MA will not respond with personal details of a potential duplicate. Your NRS should be prepared to handle such a situation visually (SDK handles it technically). Even if there are no details provided by another MA, we recommend that you still display partial information about a duplicate returned from Connect ID. Information from Connect ID and personal details from another MA are all available in the same object, so this is really easy to handle.


Method RegisterPersonAndWaitForDetailsInCaseOfDuplicates(...) returns collection of objects of PersonDuplicateWithDetails type.

This object has a couple of attributes important from our perspective:

  • Duplicate (of PersonDuplicateType type) - contains information from Connect ID (always available), i.e.:
    • Date of Birth
    • Gender
    • PlayerRegistrations (this and the next three collections contain more information that we recommend to display such as: Member Association, discipline, role and status of a registration)
    • MatchOfficialRegistrations
    • TeamOfficialRegistrations
    • OrganisationOfficialRegistrations
    • PersonFifaId
  • PersonDetails (of PersonDetails type) - contains personal details from another MA (might not be available if another MA is offline)
  • RequestRecipientOrganisationId - specifying which MA will be asked for person details
  • RequestRecipientOrganisationSystemId - in rare cases specifying a special system that is acting on behalf of a Member Association (e.g. sometimes TMS will be asked for player details if MA is not integrated with the Connect Id Service yet).

If you need any further assistance with understanding the concept of potential duplicates comparison let us know.