Transfers are subject to respective regulations and the intention of this short article is not to discuss the business aspects of transfers. We will only describe what to do technically in Connect ID in order to add a registration in a given MA (which sometimes, but not always, will become an actual transfer).


As a prerequisite, we recommend that you read this article which discusses how to build a user interface for displaying potential duplicates. Adding a registration for an existing person is always a result of a decision made by a human operator using the aforementioned user interface.


If you already determined that a person you are trying to register in your FMS, already exists internationally (you received a potential duplicate from Connect ID), you will want to take over / reuse their FIFA_ID. The process is very simple as the system automates most of the actions.


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.


Case 1 (simple) - the FIFA_ID you want to use belongs to a different MA

The only thing you need to do is to run: AddRegistration(...) method and pass information about the new registration (to indicate that this person will e.g. become an amateur, football, player, in your MA.

Note, that if a conflicting registration exists you will receive an error. In such cases it will be useful to set a Force flag to True. This setting will cause the conflicting registration to disappear and your registration to be added. Please note that the system takes care of the FIFA regulations here automatically, for example:

  • if you add a registration for Beach Soccer in your MA the system will not remove any existing registration
  • if you add a registration for Football in your MA the system will remove an existing football registration


Case 2 (advanced) - the FIFA_ID you want to use seems to already belong to your MA

We assume that you already checked that the FIFA_ID is NOT yet registered in your NRS. Yet, the record found (a potential duplicate) seems to point to your MA. How is that possible? Such a situation will happen if the record in question has been registered via a TMS user interface. TMS is currently authorised to register records on behalf of the MAs. Until they are taken over, such records will be owned by TMS. Your NRS should offer a way to differentiate between a record owned by your MA and by TMS but we don't know in details how this works on your side (if it doesn't, your technical team should look into System ID explained for guidance).


The good news is that the solution is exactly the same as in Case 1, i.e. adding a registration in your MA. This will transfer the ownership of the record to your NRS. The only difficulty in this scenario is to actually realise that this is the case and that the record needs to be transferred.


Some MAs might wonder whether it's not enough to use UpdateRegistration(...) method for a transfer. The main argument is that using AddRegistration(...) is always safe, while using the UpdateRegistration(...) might lead to mistakes. Consider two examples below.


Example 1


There is a Futsal player in MA_X. 

MA_Y uses AddRegistration(...) to add a Football registration in MA_Y.

As a result we now have 2 registrations in 2 different MAs which is OK.

If MA_Y used UpdateRegistration(...) we would replace Futsal registration with a Football one which would be wrong.


Example 2


There is a Football player in MA_X. 

MA_Y uses AddRegistration(...) to add a Football registration in MA_Y. This method takes into consideration FIFA rules automatically and removes registration in MA_X (there cannot be 2 football registrations at the same time).

As a result we now have 1 registration in MA_Y which is OK.

If MA_Y used UpdateRegistration(...) the behaviour would be identical in this case.



As you can see from these examples using AddRegistration(...) for transfers works in all cases.



Handling a conflicting registration

"The service responded with status code 400. Conflicting registrations found"


If an active registration already exists, you may receive this error. In such cases, it may be appropriate to set the Force flag of your AddRegistration operation to true.


Using the Force option will replace the conflicting registration with the new one being submitted.


Please use this functionality with care, as forceful operations may overwrite existing registrations in Connect ID. It is usually safe to use Force flag when adding a registration if you are certain that a player in currently actively playing in your Association.


You can find more information about forceful operations in the SDK documentation, or alternatively consult your development team regarding how this functionality is implemented in your system.


Note that in rare cases the conflict may also be caused by the registrations you are sending to the service. For example if you include 2 player football registrations as a parameter of AddRegistration(…) method, you will receive a 400 error although there is no conflict between what's in Connect ID and what you are sending/passing.



In connection to the topic of this article we highly recommend to read more about the concept and usage of a System ID here: https://support.id.ma.services/support/solutions/articles/7000052312-transfer-taking-over-an-existing-player