RBAC È qui che il gateway inizia a ripagarsi. In una piattaforma bancaria multi-tenant, l’accesso non può essere illimitato solo perché l’agente è “interno”. Ogni tenant necessita di una propria matrice di autorizzazioni. Un commerciante che utilizza solo l’avvio del pagamento non dovrebbe avere accesso agli strumenti KYC. Un agente di supporto in una regione non dovrebbe visualizzare i controlli sulle carte di un’altra regione. Un flusso di lavoro che richiede solo la spiegazione del saldo non dovrebbe avere accesso alla preparazione dei bonifici.
Convalida dello schema è il filtro successivo. Il gateway dovrebbe verificare la conformità di ogni richiesta alle specifiche OpenAPI approvate o a contratti equivalenti. In questo modo si individuano i payload non validi: formato della valuta errato, ID del beneficiario mancante, canale di pagamento non supportato, intervallo di date impossibile, richiesta di stato KYC non valida. Il modello può essere ben scritto e tuttavia generare un payload che il sistema dovrebbe scartare.
Flussi di lavoro di approvazione sono i casi in cui il modello non custodiale si concretizza. L’agente può preparare un’azione, ma le operazioni ad alto rischio richiedono una coda di attesa, ad esempio in presenza di soglie di importo, nuovi beneficiari, stati sospetti del conto, KYC incompleto, segnali di frode elevati o politiche specifiche per il cliente. Il gateway dovrebbe creare la richiesta di approvazione, notificarla all’approvatore, monitorare le regole di timeout e restituire uno stato chiaro all’utente o all’operatore.
Registrazione degli audit deve essere integrato nel percorso. Per ogni richiesta, il gateway dovrebbe scrivere un record di sola aggiunta. Questo record dovrebbe includere tenant, utente, canale, stato del flusso di lavoro, strumento, parametri dopo la redazione, risultato della convalida, stato di approvazione, risposta a valle e ID di correlazione. I team di conformità non hanno bisogno di una trascrizione perfetta. Hanno bisogno di una traccia chiara che spieghi perché il sistema ha consentito o bloccato l’azione.
Una distinzione che vale la pena chiarire fin dall’inizio: il log dimostra ciò che è stato eseguito, non chi avesse l’autorità per farlo. Una traccia può mostrare perfettamente che un trasferimento è avvenuto da A a B con un determinato token. Non può dimostrare, di per sé, che l’azione sia stata autorizzata da un mandante riconosciuto da entrambe le parti, né che l’autorizzazione non fosse già stata revocata. In un flusso a tenant singolo tale lacuna è invisibile, poiché il registro e i dati relativi all’autorità si trovano nello stesso posto. Nel momento in cui una controversia coinvolge un tenant o una controparte, quella lacuna diventa il problema principale. Pertanto, il registro dovrebbe riportare la legittimazione: quale mandato ha autorizzato la chiamata, con quale ambito di applicazione e se fosse ancora valido in quel momento. Approfondisco questo punto nel mio articolo Un mandato non equivale a governance.
Interruttori automatici Il problema è che i fornitori di servizi bancari falliscono in modi banali come timeout, interruzioni parziali, risposte lente, stati non aggiornati e limiti di frequenza. Il gateway dovrebbe rilevare tale schema, riprovare con un backoff quando è sicuro farlo, interrompere le chiamate ripetute quando non lo è e offrire all’utente un’alternativa utile. “Fornitore AML non disponibile, riprovare più tardi” è meglio che lasciare che l’agente entri in un ciclo infinito, inventi uno stato o continui a martellare un servizio compromesso.
Ambito di applicazione dei token limita il raggio d'azione. Una chiamata a uno strumento dovrebbe ricevere l'accesso minimo necessario per quella specifica richiesta, tenant, utente e stato del flusso di lavoro. I token a breve durata e con ambito limitato sono molto più sicuri delle credenziali di servizio a lunga durata che circolano nel livello dell'agente. Se qualcosa va storto, la richiesta fallita dovrebbe avere un impatto limitato.
Assumeteci
Chi siamo