Transfers
En resumen
Transfers handle player movement between clubs (intra-national, single tenant) and between federations (international, cross-tenant). Every dimension — transfer windows, max-per-season limits, approval chains, active-league quarantine, carta-de-libertad release letters, post-transfer eligibility delays, escalation paths, and exception conditions — is tenant-configurable, and international transfers run through the FIPJP ITC protocol over public peer-to-peer APIs between national tenants with full embedded audit trails.
Cómo funciona
A transfer request is initiated by the player or new club, then routed through a tenant-defined approval chain whose steps may include the player, old club, new club, district/region, and federation. Each tenant's transfer_config defines a window_type (always_open, deadline, or strict_period), a max-per-season limit (Sweden caps at 2; many others are unlimited), an outstanding-obligations check (Sweden blocks for up to 2 years on unpaid fees; sanctions always block), and optional carta-de-libertad / release-letter requirements. A separate quarantine flag prevents transfers while a tenant-scoped league season is active (e.g. Denmark Landsturneringen). Cross-region/cross-district moves can require additional approval (Spain: autonomous federation; France: inter-comité mutation).
When all approval steps complete, the system updates the old ClubMembership to EXPIRED, creates a new ACTIVE membership, and updates License.club_id to the new club. A configurable post-transfer competition-eligibility delay (France: ~30 days délai de carence) holds the player out of competitions in the new club for the configured period — distinct from the active-league quarantine. If any step rejects, the player can escalate to the next OrgNode level via the configured escalation path; tenants may also grant exception conditions (Germany: Wohnsitzwechsel) that bypass window restrictions when documented and federation-approved.
International transfers follow the FIPJP ITC protocol over public cross-tenant APIs: the player requests in the new nation, the new tenant calls the old tenant's public API to verify the current license, an ITC request is sent, the old tenant reviews and approves or rejects, the existing license is marked transferred-out, and the new tenant issues a license for the current season — enforcing one-nation-per-season at the data layer. Transfer fees are configurable per tenant (who pays, how much, currency) although FIPJP forbids fees on the ITC certificate itself. Every transfer carries an embedded TransferAuditEntry list with action, performer, timestamp, and status transitions, exposed through GET /transfers/{id}/audit. A unified per-player transfer history covers all clubs, all nations, and all seasons.
Capacidades clave
- Intra-national and international (cross-tenant) transfer workflows
- Tenant-configurable window types, max-per-season limits, and approval chains
- Outstanding-obligations and active-sanction blocking with configurable lookback
- Carta-de-libertad / release-letter submit-verify-reject workflow
- ITC generation and verification over public peer-to-peer APIs between tenants
- Post-transfer competition-eligibility delay and active-league quarantine
- Refusal escalation, exception conditions, and full embedded audit trail
En la práctica
A French player wants to move from JS Marseille to AS Lyon mid-season. The system checks the FFPJP transfer window — closed — and surfaces the option to request an exception. The player files for inter-comité mutation; the request enters the configured chain: old club approves, new club approves, comité 13 approves, comité 69 approves, then the FFPJP signs off.
The system updates ClubMembership records, moves the license to AS Lyon, and sets a 30-day délai de carence. The player sees the new club affiliation in their profile but is blocked from entering competitions for AS Lyon until the eligibility date. The full chain — every approver, timestamp, and comment — is queryable via the audit endpoint, and the player's transfer history now lists both clubs against the 2026 season.
Funcionalidades de este subsistema
19| ID | Status | Funcionalidades |
|---|---|---|
| F03.03.01 | Entregado | Intra-national club transfer (OrgNode change within same tenant) — PL-F0303a ✅ PL-F0303a |
| F03.03.02 | Entregado | International transfer (cross-tenant, nation to nation via public APIs) — PL-F0303a ✅ PL-F0303a |
| F03.03.03 | Entregado | Configurable transfer window per tenant — open period (Germany: Nov-Dec), free period before deadline (Sweden), or always open (Denmark). Tenant admin configures. — PL-F0303a ✅ PL-F0303a |
| F03.03.04 | Entregado | Configurable transfer approval workflow per tenant — who must approve (player, old club, new club, federation, district/region). Each step configurable. — PL-F0303a ✅ PL-F0303a |
| F03.03.05 | Entregado | Max transfers per season — configurable limit per tenant (Sweden: 2, others: unlimited) — PL-F0303a ✅ PL-F0303a |
| F03.03.06 | Entregado | Transfer quarantine during active league — configurable: player cannot transfer while league season is active (Denmark Landsturneringen). Tenant-scoped league check. — PL-F0303b ✅ PL-F0303b |
| F03.03.07 | Entregado | Cross-region/cross-district transfer — additional approval required when transferring between OrgNode subtrees (Spain: autonomous federation approval, France: inter-comité mutation). Configurable approval type per tenant. — PL-F0303b ✅ PL-F0303b |
| F03.03.08 | Entregado | Outstanding obligations check — system blocks transfer if player has unpaid fees/active sanctions. Configurable blocking period (Sweden: max 2 years). Sanctions always checked. — PL-F0303b ✅ PL-F0303b |
| F03.03.09 | Entregado | Carta de libertad / release letter — some nations require formal release document from departing club. Configurable per tenant. Submit/verify/reject workflow. — PL-F0303b ✅ PL-F0303b |
| F03.03.10 | Entregado | ITC generation and verification via public API (peer-to-peer between tenants). Verify endpoint validates authenticity and status. — PL-F0303b ✅ PL-F0303b |
| F03.03.11 | Entregado | ITC workflow: player requests in new nation → new nation verifies license status via public API → sends ITC request → old nation reviews and approves/rejects → license marked "transferred out" → new nation issues license — PL-F0303c ✅ PL-F0303c |
| F03.03.12 | Entregado | Transfer fee handling — configurable per tenant (who pays, amount) — PL-F0303c ✅ PL-F0303c |
| F03.03.13 | Entregado | Transfer history per player (all clubs, all nations, all seasons) — PL-F0303c ✅ PL-F0303c |
| F03.03.14 | Entregado | One-nation-per-season validation on international transfer — PL-F0303c ✅ PL-F0303c |
| F03.03.15 | Entregado | Post-transfer competition eligibility delay — configurable per tenant (France: délai de carence ~30 days after mutation before player is competition-eligible in new club). Distinct from transfer quarantine (F03.03.06). — PL-F0303c ✅ PL-F0303c |
| F03.03.16 | Entregado | Transfer refusal appeal/escalation — when a step in the transfer workflow is rejected (e.g., old club refuses), player can escalate to higher OrgNode level (France: appeal to comité départemental). Configurable escalation path per tenant. — PL-F0303d ✅ PL-F0303d |
| F03.03.17 | Entregado | Transfer exception conditions — configurable per tenant: allow transfer outside normal window if specific conditions are met (Germany: Wohnsitzwechsel/residence change). Exception must be documented and approved by federation. — PL-F0303d ✅ PL-F0303d |
| F03.03.18 | Entregado | Multi-club membership toggle — configurable per tenant: some nations allow support membership in multiple clubs (Sweden), others forbid all multi-club affiliation (France: double appartenance interdit). — PL-F0303d ✅ PL-F0303d |
| F03.03.19 | Entregado | Audit trail on all transfers — embedded TransferAuditEntry list with action, performer, timestamp, status transitions. Audit endpoint GET /transfers/{id}/audit. — PL-F0303d ✅ PL-F0303d |