Sottoprogetti integrati
Piattaforme broker collegate
Onboarding automatizzato
Il Contesto
Il progetto e stato realizzato per una societa di prop trading con operativita internazionale. Il modello di business e quello tipico del settore: il trader si registra, supera una fase di valutazione su conto demo e, una volta qualificato, opera su capitale finanziato dalla societa, condividendone i profitti. Per ragioni di riservatezza commerciale il nome della societa, il numero di clienti e i volumi di trading non vengono divulgati.
Questo modello regge solo se l'intera filiera software — registrazione, verifica identita, pagamenti, assegnazione del conto, esecuzione sulle piattaforme broker e affiliazione — funziona in modo coordinato. E proprio questo coordinamento, all'inizio, mancava: l'azienda aveva accumulato strumenti separati, in parte manuali, che non parlavano tra loro.
Il Problema
La crescita aveva fatto emergere i limiti di un'infrastruttura nata per frammenti. I punti dolenti erano tre, tutti con impatto diretto sui costi operativi e sul rischio.
- Onboarding lento e presidiato a mano: la verifica documentale (KYC) e l'attivazione del conto richiedevano passaggi manuali del backoffice, con tempi di attesa per il cliente e carico di lavoro che cresceva linearmente con le iscrizioni.
- Frammentazione tra le piattaforme di trading: la societa operava su MatchTrader, cTrader e Tradelocker, ognuna con API, modelli dati e logiche di sessione propri. Ogni nuova integrazione era un progetto a se, senza un livello comune che la astraesse.
- Backoffice senza vista unica: gli operatori dovevano consultare sistemi diversi per seguire un singolo cliente lungo il suo ciclo di vita, con dati duplicati e nessuna fonte di verita unica su stato KYC, pagamenti e conti attivi.
L'obiettivo concordato era costruire un ecosistema unico e modulare: automatizzare l'onboarding end-to-end, dare al backoffice una vista coerente sull'intero ciclo di vita del cliente e isolare la complessita dei broker dietro un'unica interfaccia interna, in modo da poterne aggiungere di nuovi senza riscrivere il resto.
La Soluzione
Invece di un monolite unico, l'ecosistema e stato organizzato in tre macro-aree autonome che comunicano tra loro tramite contratti espliciti. Questa scelta ha permesso di far evolvere e rilasciare ogni area in modo indipendente, riducendo il blast radius di ogni modifica.
1. Area clienti e onboarding
Il portale rivolto al trader e costruito su Laravel 9 con frontend Vue 3. Gestisce registrazione, KYC (verifica identita e documenti), pagamenti e acquisto dei challenge di valutazione. L'onboarding e stato reso automatico: superata la verifica, il sistema attiva il conto e innesca l'assegnazione sulla piattaforma broker corretta senza intervento manuale.
2. Backoffice operativo
Lo strumento interno per il team dell'azienda offre la vista unica che prima mancava: stato KYC, storico pagamenti, conti attivi e progressione del trader nella valutazione, tutto in un solo posto. E un'applicazione Vue 3 con tabelle avanzate, filtri e grafici, alimentata dagli stessi servizi che servono l'area clienti, cosi da eliminare i dati duplicati.
3. Gateway di trading multi-broker
Il cuore tecnico e un servizio NestJS che fa da gateway verso le tre piattaforme broker. Espone alle altre aree un'unica interfaccia interna via gRPC e traduce ogni richiesta nel dialetto del broker di destinazione (MatchTrader, cTrader, Tradelocker). Gli aggiornamenti che devono arrivare in tempo reale — stato dei conti, eventi di sessione — viaggiano su WebSocket. Aggiungere un quarto broker significa scrivere un nuovo adapter, non toccare l'area clienti o il backoffice.
Tecnologie Chiave
Lo stack mescola deliberatamente due ecosistemi: PHP/Laravel per la parte gestionale e ricca di dominio, Node/NestJS per i servizi real-time e di integrazione. Ogni scelta risponde a un'esigenza precisa.
Backend dell'area clienti: dominio ricco, autenticazione, pagamenti e flussi KYC con un framework maturo e produttivo.
Frontend sia dell'area clienti sia del backoffice: reattivita, componenti riutilizzabili e tabelle dati complesse.
Servizi di integrazione e gateway broker: architettura modulare e tipizzata, ideale per orchestrare adapter multipli.
ORM tipizzato per i servizi Node: query sicure e migrazioni versionate sul lato dei microservizi.
Canale push per stato conti ed eventi di sessione in tempo reale verso backoffice e area clienti.
Contratto interno tra i servizi: comunicazione efficiente e fortemente tipizzata tra area clienti, backoffice e gateway.
Persistenza flessibile per dati eterogenei dei broker ed eventi di trading dal formato variabile.
Database relazionale per i dati transazionali dell'area clienti: utenti, pagamenti e stato KYC.
Containerizzazione di ogni servizio: ambienti riproducibili e deploy coerente dell'intero ecosistema.
Il Risultato
Il risultato e una filiera coerente al posto di strumenti scollegati: il cliente passa da registrazione a conto operativo senza colli di bottiglia manuali, e l'azienda governa l'intero ciclo da un unico backoffice.
Sottoprogetti integrati
Piattaforme di trading collegate
Onboarding automatizzato
I dati indicati sono indicativi e stimati, riferiti alla portata del lavoro svolto su un progetto soggetto a riservatezza. Non rappresentano metriche commerciali del cliente ne valori certificati da audit esterni.
Sfide Tecniche
Astrarre tre broker dietro un'unica interfaccia
MatchTrader, cTrader e Tradelocker espongono API, modelli dati e cicli di sessione profondamente diversi. La sfida era evitare che queste differenze contaminassero l'area clienti e il backoffice. La soluzione e stata un pattern adapter nel gateway NestJS: un'interfaccia gRPC unica verso l'interno, e un adapter per broker che incapsula autenticazione, mappatura dei modelli e gestione degli errori specifici. Il resto dell'ecosistema parla un solo linguaggio; l'eterogeneita resta confinata dietro il gateway.
Sincronizzare stato real-time tra servizi eterogenei
Lo stato di un conto deve essere coerente tra il broker, il gateway, il backoffice e l'area clienti, ciascuno con il proprio ritmo. La sfida era propagare gli aggiornamenti in tempo reale senza accoppiare strettamente i servizi. Ho separato i due piani: gRPC per le richieste sincrone (comandi e query con contratto forte) e WebSocket per il flusso push di eventi e variazioni di stato. Cosi un cambiamento sul broker raggiunge il backoffice in tempo reale senza che le aree debbano interrogarsi a vicenda in polling.
Per il profilo professionale e l'esperienza su piattaforme fintech enterprise vedi la pagina Chi sono; per gli altri progetti vedi il portfolio completo.
