Please note that you should use Connect ID pre-production environment credentials for testing of the Clearing House messages with TMS. This will send messages to TMS staging environment. [29th June 2022] Please also take note that the latest version of the SDK contains breaking changes to the data model of SDK’s communication with the Clearing House. This concerns the following versions of the SDK: - .NET SDK: 6.1.1682 - Java SDK: 6.2.784 - PHP SDK: 6.1.1413 You will need to implement these latest SDKs for the Clearing House interface to work, but keep in mind that you will not be able to test the actual interface (i.e. send ProofOfPayment, FirstProRegistration or the DomesticTransferDeclaration messages) until the TMS Team introduces the necessary changes on their side. This is estimated to happen in July 2022. For additional details on the Clearing House interface contact ClearingHouse@fifa.org. [5th July 2022] TMS Team upgraded the SDK on their side and it is now possible to test the Clearing House interface in pre-production environment (after upgrading to the above mentioned SDK versions).
New versions of Connect Id SDKs are now available allowing Member Associations to implement Clearing House requirements. Release notes can be found here.
TABLE OF CONTENTS
- 1. Domestic Transfer Declaration
- 2. Proof of Payment
- 3. First Pro Registration
- 4. Mandatory and optional data to be sent as part of the Clearing House integration
This article provides an overview of the integration process, business context and more technical details. It is mandatory reading for a developer attempting to implement the integration between the MA's system(s), e.g. the National Registration System (NRS) and the Domestic Transfer System (DTS), and the Clearing House.
In practice, most MAs will operate one single Football Management System comprising both NRS and DTS functionality; in this case, NRS and DTS will effectively describe the same system. In this case, all 3 methods will have to be implemented.
In case an MA operates its own NRS but uses FIFA's DTMS as a DTS, it only needs to implement the "First Pro Registration" method.
Clarification: although this article talks about the integration with both TMS and the Clearing House, in fact MAs integrate with TMS only. This is done in order to satisfy the Clearing House requirements but the communication is always to TMS, FIFA's central transfer system. Also, it is TMS that will request data from MAs in order to build a player's passport for the sake of the Clearing House.
Please note, that FIFA Connect Id Service does not take part in any business process related to the Clearing House. In particular it does not store information related to transfers of players. It merely enables the information to be exchanged between the MA system(s) and TMS.
Prerequisite: in order to start the TMS integration, MA needs to be integrated with the FIFA Connect Id Service first. Guiding resources for that process are:
- Step-by-step instruction - taking you gradually through all the required steps of integration
- Integration approach and checkpoints - article explaining conditions of advancing through the integration phases
- Mandatory and optional data - important to read, as the ability of an MA to send a full Electronic Player Passport (EPP), including the registrations history, is also a prerequisite for the Clearing House integration
This article assumes that you are familiar with the integration concepts discussed or implemented during the Connect Id integration. This is done on purpose in order to make the TMS integration easier by making references to the concepts already known.
Technical documentation for methods, including the snippets of code, can be found in the main SDK documentation, under chapter 6. [Optional] Transfer Matching System (TMS) integration.
There are 3 types of messages that need to be implemented in order to satisfy the Clearing House requirements:
- Domestic Transfer Declaration
- Proof of Payment
- First Pro Registration
The general process flow is the following:
- MA informs TMS about a transfer using Domestic Transfer Declaration message
- TMS sends back tmsTransferId which is saved by MA
- according to the payments schedule, MA sends 1 or more payment messages using Proof of Payment message which are all bound to a particular transfer identified by tmsTransferId
1. Domestic Transfer Declaration
All domestic transfers with transfer fees between the clubs (other than training compensation) need to be declared to TMS/ the Clearing House by the MA's DTS using the relevant SDK method.
Through a Domestic Transfer Declaration, MA informs the TMS that a domestic transfer took place. Full specification of the message is available in SDK but at the general level, the message consists of the following parts:
- information about a player being transferred - this is a well known PersonLocal object used when replying to other MAs with person details
- information about player's registrations - as above: included in PersonLocal object. In this case, exactly one registration is required. As part of the PlayerRegistrationType passed in the PersonLocal object, Member Association should send across the registration details of the player at the engaging club.
- information about an engaging club - new ClubType class has been created for this purpose
- information about a releasing club - like above
- transfer information - this section is new, i.e. there was no need during the Connect Id integration to process this information. Key part of the transfer information is the definition of payments
Similarly to the request for person details - known from the Connect Id integration - domestic transfer declaration requires an answer. What the TMS returns is a tmsTransferId which needs to be saved by the MA. It will be later used to assign payments to a particular transfer (see the proof of payment).
2. Proof of Payment
This is a complimentary message for a Domestic Transfer Declaration, also to be declared to TMS/ the Clearing House by the MA's DTS using the relevant SDK method.
The message itself is simple and consists of:
- tmsTransferId - acquired during the Domestic Transfer Declaration
- information about the payment (type, amount, currency, date)
- recipient club info
3. First Pro Registration
The MA's NRS must communicate the details of each change of status of a player from amateur to professional to FIFA, including confirmation by the member association if the player has been trained at another Member Association.
The information about a first registration as a professional should not be communicated to FIFA in case the player is being transferred from another member association when becoming a professional, i.e. in the case of an international transfer. Such cases will be handled by the TMS application as part of the international transfer.
Please note that for one player, a "first registration as a professional" could happen more than once. Eg. if a player is registered in Club x as an amateur, is then transferred to Club y as professional, reacquires amateur status at Club y before being transferred to Club z as a professional (all within the same association), the relevant Member Association would have to send the “first professional registration” information to FIFA twice (from x to y and from y to z).
Attention: A player that is being registered as a professional as a result of an international transfer to your Member Association, should NOT trigger a FPR message, as these cases are already captured by the TMS system when the international transfer is entered.
Through this message, an MA informs TMS about the first professional registration of a given player. The message itself is quite simple and consists mostly of already defined elements:
information about the player being registered - same as in case of a Domestic Transfer Declaration (PersonLocal)
information about player's registrations - in this case exactly one registration is required. As part of the PlayerRegistrationType passed in the PersonLocal object, Member Association should send along the registration details of the player at the engaging club.
- club information - this is ClubType as defined for a Domestic Transfer Declaration
- club status
- PlayerTrainedInOtherMemberAssociation - this is a simple yes/no information. This value is of special importance to the Clearing House to determine whether the player whether the training contribution will have to be paid through the Clearing House.
The steps that should be followed from a technical perspective in order to successfully implement the Clearing House requirements are pretty straightforward and well described in SDK documentation (6. [Optional] Transfer Matching System (TMS) integration). There are some remarks worth taking into account:
- Similar to the Connect Id integration, where a registrationFacade is used, all TMS communication requires a tmsFacade to be created and configured. Follow chapter 6.1 Create TMS facade here and mind the fact that the same service bus client is used for both facade objects.
- For sending all Clearing House messages there are dedicated methods. Similarly, new classes have been created for all messages, and sending methods take objects of those classes as parameters (e.g. tmsFacade.DeclareDomesticTransferAndWaitForTransfer will take an object of class DomesticTransferDeclaration as a parameter). It is not possible to send XML directly. This was done in order to avoid confusion on the MAs side but also to increase the quality by enforcing the proper validation of messages.
4. Mandatory and optional data to be sent as part of the Clearing House integration
Below you can find all mandatory fields to be sent as part of the Clearing house integration. The messages are also definde in more detail (including also optional fields) in the corresponding XSD as included in the Connect ID SDKs.
Domestic Transfer Declaration
Data field | Data type |
MessageId | Unique identifier of the message, e.g. local transfer Id. |
Person | FCDS PersonLocalType, includes:
|
EngagingClub | FCDS ClubType, includes:
|
ReleasingClub | FCDS ClubType, includes:
|
All transfer fees, including
| FCDS FeeType, includes:
|
PlayerLevelInReleasingClub | Amateur/ Pro |
PlayerLevelInEngagingClub | Amateur/ Pro |
TransferNature | Loan/ permanent/ loan to permanent/ loan extension/ return from loan |
SellOnFee | yes/ no/ not available |
Contract end date | Date |
Proof of Payment
Data field | Data type |
MessageId | Unique identifier of the message, e.g. local payment Id. |
Fee | FCDS FeeType, includes:
|
TMSTransferId | long |
PaymentType | fixed transfer fee/ release buy-out fee/ conditional transfer fee/ sell-on fee |
First Pro Registration
Data field | Data type |
MessageId | Unique identifier of the message. |
Person | FCDS PersonLocalType, includes:
|
Club | FCDS ClubType, includes:
|
ClubStatus | Active/ Inactive |
PlayerTrainedInOtherMemberAssociation | Boolean (yes/ no) |
Electronic player passport (EPP)
In addition, you will also have to send all registrations a player has had with clubs affiliated to your Member Associations, when asked for Person details via the FIFA Connect ID Service Bus. This works though the message GetPersonDetails
on PersonDetailsProvider
. The registration data generated through this Interface will be used generate the EPP for the Clearing House.
All details are explained in the following article, section 2: Mandatory and optional data