Abbiamo iniziato rendendo espliciti i meccanismi del motore delle politiche attraverso domain learning. Le politiche in questo contesto combinano condizioni su indicatori comportamentali come fingerprint del dispositivo, cambio di posizione, velocità di spesa e cronologia dei fallimenti precedenti con risultati come consentire, bloccare o attivare autenticazione rafforzata. L'interfaccia esistente esponeva queste regole come viste di database e tabelle di configurazione. Non corrispondeva a come gli analisti ragionano sui pattern di frode o come spiegano le decisioni ai team di audit interno.

Attraverso workshop con specialisti di prodotto, tecnici e di sicurezza di Callsign durante Sandbox Experiments abbiamo mappato le strutture di regole esistenti, gli scenari di frode che dovevano coprire e i punti in cui apparivano conflitti o lacune. Questo esercizio di mappatura ha portato a una chiara separazione tra il modello di rilevamento frodi che assegna punteggi agli eventi e il livello delle politiche che applica soglie, override e decisioni del flusso di lavoro. Il lavoro è diventato un pezzo di progettazione UX per sistemi di IA dove l'interfaccia controlla come gli output del modello fluiscono in azioni del mondo reale.

Da lì abbiamo definito un'architettura dell'informazione per la sicurezza aziendale che trattava una politica come oggetto centrale. Ogni politica raggruppa le sue condizioni, azioni, cronologia e collegamenti a regole correlate. Gli analisti possono seguire una politica dalla definizione fino alla valutazione senza uscire dal contesto. Le decisioni sono registrate in modo da supportare la revisione di audit e i controlli normativi relativi a SCA, PCI DSS e governance interna. Abbiamo validato le prime versioni di questa struttura con i team di Callsign utilizzando scenari concisi piuttosto che diagrammi astratti, e abbiamo adattato in base al loro feedback.

Con l'architettura in atto, abbiamo riprogettato i percorsi degli analisti per riflettere come i team antifrode pensano effettivamente a un caso. L'esperienza precedente costringeva gli utenti a saltare tra schermate di configurazione, documenti di riferimento e tabelle di dati quando volevano modificare una singola regola. L'abbiamo sostituita con un flusso incentrato sulle politiche. Gli analisti identificano uno scenario, aprono il set di politiche rilevante, regolano le condizioni nel contesto e vedono immediatamente dove nel flusso di lavoro si applica la modifica.

Il concetto di interazione principale era un modello a tre gesti progettato per interaction design per analisti di frodi. Gli analisti trascinano per creare o riposizionare nodi nel flusso di lavoro, cliccano per aprire e modificare i parametri delle regole inline e disegnano una connessione per collegare i nodi e definire la sequenza. Questi gesti sono coerenti in tutto lo strumento, il che mantiene basso lo sforzo di apprendimento per gli utenti che provengono da background di rischio o compliance piuttosto che di prodotto.

Abbiamo anche dovuto fare compromessi sullo scope attraverso tension-driven reasoning. Per la prima release abbiamo dato priorità alla creazione di politiche, alla visibilità dei conflitti e alla spiegazione dell'impatto rispetto a funzionalità di collaborazione avanzate o viste complete della cronologia delle versioni. Questa decisione rifletteva l'obiettivo immediato di rendere efficaci e credibili le demo con i team di rischio e sicurezza delle grandi banche. I test interni iniziali con gli analisti di Callsign hanno confermato che i nuovi percorsi hanno ridotto il tempo necessario per esprimere uno scenario di frode comune nello strumento e hanno reso più dirette le spiegazioni durante le chiamate con i clienti.

La sola configurazione non era sufficiente. Callsign necessitava di un modo per consentire agli analisti e agli stakeholder bancari di comprendere cosa avrebbe fatto un dato insieme di politiche in scenari realistici. Abbiamo creato una modalità di valutazione in cui gli utenti definiscono un contesto di simulazione utilizzando filtri in stile linguaggio naturale come segmento di clientela, geografia o tipo di transazione. Il sistema esegue quindi queste impostazioni attraverso il modello di rilevamento frodi e il motore delle politiche e presenta i risultati in una vista analitica focalizzata.

La vista di valutazione è centrale per l'esperienza utente negli strumenti di gestione del rischio perché chiude il ciclo tra configurazione e impatto. Gli analisti possono vedere quanto spesso uno scenario porterebbe all'approvazione automatica, all'autenticazione rafforzata o al blocco, e possono verificare se i casi ad alto rischio sfuggirebbero. Per rendere questo interpretabile ci siamo affidati alla visualizzazione dei dati per sistemi bancari implementata con D3, utilizzando rappresentazioni a grafo e flusso che evidenziano dove il traffico si concentra e dove le politiche creano colli di bottiglia.

Abbiamo mantenuto molto chiara la relazione tra configurazione e valutazione. Le politiche vengono sempre modificate nello spazio di configurazione, e l'ambiente di valutazione consuma queste definizioni senza permettere agli utenti di modificarle sul posto. Questa protezione evita modifiche non tracciate durante l'analisi. Abbiamo utilizzato UX basata sull'evidenza per l'IA per raffinare il flusso di valutazione, osservando come gli analisti interpretavano i grafici e dove si verificavano errori di lettura, quindi semplificando etichette e interazioni di conseguenza. Il risultato è un ciclo controllato ma flessibile in cui gli analisti possono testare, regolare e giustificare le strategie delle politiche senza esporre gli elementi interni del modello.

Dalle prime settimane abbiamo trattato ogni schermata come parte di un design system piuttosto che come artefatto singolo durante Concept Convergence. Il sistema copre la costruzione del flusso di lavoro, la gestione delle politiche, le viste di valutazione e le strutture di navigazione di supporto. Ogni componente ha stati documentati, regole di interazione e note di utilizzo. Questa base è diventata un design system per prodotti bancari che aiuta Callsign a mantenere la coerenza tra le nuove funzionalità di sicurezza e i moduli futuri.

Sul lato tecnico ci siamo allineati presto con il team front-end. I componenti di politica e flusso di lavoro sono stati modellati come unità React che possono essere composte per creare schermate più complesse senza duplicazione. Ad esempio, lo stesso modulo di riepilogo delle politiche appare negli elenchi di configurazione, nella tela del flusso di lavoro e nei risultati di valutazione, con un contratto di comportamento coerente. Le visualizzazioni basate su D3 si trovano all'interno di contenitori React dedicati così le responsabilità di layout e rendering sono chiaramente separate, il che supporta l'ottimizzazione delle prestazioni per dataset più grandi.

Abbiamo strutturato i deliverable per adattarsi al loro processo di sviluppo durante Implementation Partnership. Le specifiche seguivano la struttura del loro lavoro esistente in Git e Confluence, e ci siamo uniti a sessioni regolari con gli ingegneri per risolvere edge case prima che raggiungessero l'implementazione. Dopo circa otto settimane il progetto ha raggiunto uno stato stabile. I nuovi flussi di lavoro e le interfacce di gestione delle politiche erano pronte per le demo aziendali e il design system era abbastanza completo da guidare ulteriori lavori interni. I designer di Callsign hanno successivamente utilizzato questo sistema come base per moduli aggiuntivi oltre alle frodi e all'autenticazione.