Introduction

As explained in the article Connect ID Notifications there are profound benefits to having all the players' data synchronised between Member Associations (MA) Football Management Systems (FMS). Electronic Player Passport (EPP) and Notifications can only function properly if Connect ID Service knows which MA stores data of a given FIFA_ID (i.e. is a data holder).

It would seem at first glance that when MA gets onboarded, i.e. it generates FIFA_IDs for all their players, Connect ID Service has a full picture of which FIFA_IDs are stored by that MA. Unfortunately that is not entirely correct because of one scenario. Let's look at an example:

  • during the onboarding process MA_X tries to register John Smith born on 1978-04-23
  • it turns out, however, that John Smith previously played for MA_Y and as they happened to be onboarded earlier than MA_X, John Smith already has a FIFA_ID
  • MA_X writes down that existing FIFA_ID in their FMS therefore avoiding the data duplication

This is the correct process but as a result Connect ID Service does not know that MA_X is a data holder of John Smith. As a consequence:

  • Connect ID notifications about any potential changes to John Smith (e.g. transfers or personal data changes) are not sent to MA_X
  • during the generation of EPP for John Smith, MA_X will not* be asked for details
*In order to address this process flow, the EPP generation process currently involves all MAs. Requests for details of a given player are sent to all MAs generating a lot of unnecessary traffic.


Starting from August 2022 (see the release notes), the Connect ID Service includes the functionality that solves the abovementioned problem. A new SDK method is introduced, called RegisterAsDataHolderOfPerson(FIFA_ID). This method should be called by a Member Association whenever they store an existing FIFA_ID in their FMS but don't cause any changes in the Connect ID Service.

Functionality rollout

The expected rollout of the functionality consists of two steps that each and every MA needs to perform in the specified order.

Step 1 - introducing RegisterAsDataHolderOfPerson(...)

In most cases the only thing that needs to be modified on the MA side is the duplicate resolution process. Whenever they would previously store the FIFA_ID without sending any request to the Connect ID Service, they now need to call RegisterAsDataHolderOfPerson(...) method explicitly. This will tell the Connect ID that this particular MA became a data holder of a given FIFA_ID.

Note that this is necessary only if there is no data changing request sent to the Connect ID Service. In any of the following cases it is not necessary to call the method explicitly:

  • if a new person is registered and FIFA_ID received
  • if an existing person is updated (e.g. date of birth or name)
  • if any of the registrations are updated (e.g. activating or deactivation a registration)
  • if a person is transferred

Step 2 - bulk claiming of all FIFA_IDs stored

When a Member Association successfully incorporates the RegisterAsDataHolderOfPerson(...) method into their process, we need to make sure that the Connect ID Service knows about all the FIFA_IDs they have stored up to date. This is a one time process and we picked an approach which is by far the easiest for a Member Association as it doesn't require any development.

Member Association needs to export all of the FIFA_IDs they store in the form of a CSV file (one FIFA_ID per line, ideally no quotation marks). No other information is required, just the list of FIFA_IDs. This file (or a link to the file) should be then sent to support.id@fifa.org. Connect ID Team will reach out and confirm when the file has been properly loaded.

Please note, that if a given NRS keeps information about merges, i.e. for merged record keeps both the "secondary" (old) and the "primary" (new) record, "secondary" records should not be exported. If they are, they will be marked by our processing and we will come back to you asking to make sure that you are not actively using "secondary" records.


Let us emphasize once again, that this step may only happen after an MA has implemented and released support for the RegisterAsDataHolderOfPerson(...) method.

Summary

When an MA goes through both steps of the rollout process we would be able to say the following:

  • the Connect ID Service knows about each FIFA_ID stored by that MA
  • going forward, the Connect ID Service will know about each future FIFA_ID stored by that MA

This will allow both EPP and Notifications to function properly and efficiently, i.e. without sending unnecessary requests.


FAQ

Is it possible to test that RegisterAsDataHolderOfPerson(...) call has been successful?

Yes. Although the method will return 202 when successful so there is no need to check additionally, you can still do this for testing purposes. To do this call GetDataHoldersOfPerson(...) as described in SDK documentation chapter 3.2.11 Data holders. Also check the documentation to handle rare cases when the FIFA_ID you try to register as a data holder of, has been merged or deleted.