Vi startet med å gjøre mekanikken i policy-motoren tydelig gjennom domain learning. I denne sammenhengen kombinerer policyer betingelser basert på atferdsindikatorer som enhetsfingeravtrykk, endringer i lokasjon, transaksjonshastighet og tidligere feilhistorikk, med utfall som å tillate, blokkere eller utløse stegvis autentisering. Det eksisterende grensesnittet viste disse reglene som databasevisninger og konfigurasjonstabeller. Det samsvarte ikke med hvordan analytikere resonerer om svindelmønstre eller hvordan de forklarer beslutninger til interne revisjonsteam.

Gjennom workshops med Callsigns produkt-, engineering- og sikkerhetsspesialister under Sandbox Experiments kartla vi eksisterende regelstrukturer, svindelscenariene de måtte dekke, og punktene der konflikter eller hull oppstod. Denne kartleggingsøvelsen førte til et tydelig skille mellom svindeldeteksjonsmodellen som scorer hendelser, og policy-laget som anvender terskler, overstyringer og arbeidsflytbeslutninger. Arbeidet ble et eksempel på UX-design for AI-systemer, der grensesnittet styrer hvordan modellens utdata omsettes til handlinger i den virkelige verden.

Deretter definerte vi en informasjonsarkitektur for enterprise-sikkerhet som behandlet en policy som det sentrale objektet. Hver policy samler sine betingelser, handlinger, historikk og lenker til relaterte regler. Analytikere kan følge en policy fra definisjon til evaluering uten å miste kontekst. Beslutninger registreres på en måte som støtter revisjon og regulatoriske kontroller knyttet til SCA, PCI DSS og intern styring. Vi validerte tidlige versjoner av denne strukturen med Callsign-teamene ved hjelp av konsise scenarier i stedet for abstrakte diagrammer, og justerte basert på tilbakemeldingene deres.

Med arkitekturen på plass redesign­et vi analytikerreisene for å gjenspeile hvordan svindelteam faktisk tenker gjennom en sak. Den tidligere opplevelsen tvang brukerne til å hoppe mellom konfigurasjonsskjermer, referansedokumenter og datatabeller når de ønsket å justere én enkelt regel. Vi erstattet dette med en policy-sentrert flyt. Analytikere identifiserer et scenario, åpner det relevante policy-settet, justerer betingelser i kontekst og ser umiddelbart hvor i workflowen endringen gjelder.

Kjerneinteraksjonskonseptet var en tre-gests-modell utviklet for interaksjonsdesign for svindelanalytikere. Analytikere drar for å opprette eller flytte noder i arbeidsflyten, klikker for å åpne og redigere regelparametere direkte, og tegner en forbindelse for å koble noder og definere rekkefølge. Disse gestene er konsistente i hele verktøyet, noe som holder læringsinnsatsen lav for brukere med bakgrunn innen risiko eller compliance fremfor produkt.

Vi måtte også gjøre scope trade offs gjennom tension-driven reasoning. For første lansering prioriterte vi opprettelse av policyer, synlighet av konflikter og forklaring av konsekvenser fremfor avanserte samarbeidsfunksjoner eller full versjonshistorikk. Denne beslutningen reflekterte det umiddelbare målet om å gjøre demonstrasjoner for risiko- og sikkerhetsteam i store banker effektive og troverdige. Tidlig intern testing med Callsigns analytikere bekreftet at de nye brukerreisene reduserte tiden det tok å uttrykke et vanlig svindelscenario i verktøyet, og gjorde forklaringer under kundesamtaler mer rett frem.

Konfigurasjon alene var ikke nok. Callsign trengte en måte for analytikere og bankinteressenter å forstå hva et gitt sett med policyer ville gjøre i realistiske scenarier. Vi utviklet en evalueringsmodus der brukere definerer en simuleringskontekst ved hjelp av filtre i naturlig språk, som kundesegment, geografi eller transaksjonstype. Systemet kjører deretter disse innstillingene gjennom svindeldeteksjonsmodellen og policy-motoren, og presenterer resultatene i en fokusert analytisk visning.

Evalueringsvisningen er sentral for brukeropplevelsen i risikostyringsverktøy, fordi den lukker loopen mellom konfigurasjon og effekt. Analytikere kan se hvor ofte et scenario fører til automatisk godkjenning, stegvis autentisering eller blokkering, og sjekke om høyrisikosaker slipper gjennom. For å gjøre dette forståelig brukte vi data visualisation for banksystemer, implementert med D Three, med graf- og flytrepresentasjoner som viser hvor trafikken samler seg og hvor policyer skaper flaskehalser.

Vi holdt forholdet mellom konfigurasjon og evaluering svært tydelig. Policyer redigeres alltid i konfigurasjonsområdet, og evalueringsmiljøet bruker disse definisjonene uten å la brukere endre dem direkte. Denne beskyttelsen forhindrer uregistrerte endringer under analyse. Vi brukte evidence based UX for AI til å forbedre evalueringsflyten, ved å observere hvordan analytikere tolket grafene og hvor misforståelser oppstod, og deretter forenkle etiketter og interaksjoner. Resultatet er en kontrollert, men fleksibel sløyfe der analytikere kan teste, justere og begrunne policy-strategier uten å eksponere modellens interne mekanismer.

Allerede fra de første ukene behandlet vi hver skjerm som en del av et design system, ikke som et enkeltstående artefakt under Concept Convergence. Systemet dekker bygging av arbeidsflyter, policy-håndtering, evalueringsvisninger og støttende navigasjonsstrukturer. Hver komponent har dokumenterte tilstander, interaksjonsregler og bruksnotater. Dette fundamentet ble et design system for bankprodukter som hjelper Callsign å opprettholde konsistens på tvers av nye sikkerhetsfunksjoner og fremtidige moduler.

På engineering-siden samarbeidet vi tidlig med front end-teamet. Policy- og workflow-komponenter ble modellert som React-enheter som kan settes sammen for å lage mer komplekse skjermer uten duplisering. For eksempel vises den samme policy-oppsummeringsmodulen i konfigurasjonslister, i workflow-canvasen og i evalueringsresultater, med en konsistent adferdskontrakt. D Three-baserte visualiseringer ligger i egne React-containere, slik at ansvar for layout og rendering er tydelig adskilt, noe som støtter ytelsesoptimalisering for større datasett.

Vi strukturerte leveransene for å passe inn i deres utviklingsprosess under Implementation Partnership. Spesifikasjonene fulgte strukturen i deres eksisterende arbeid i Git og Confluence, og vi deltok i regelmessige økter med ingeniører for å løse edge cases før de nådde implementering. Etter rundt åtte uker hadde prosjektet nådd en stabil tilstand. De nye workflowene og grensesnittene for policy-håndtering var klare for enterprise-demoer, og design systemet var tilstrekkelig komplett til å veilede videre internt arbeid. Callsigns egne designere brukte senere dette systemet som grunnlag for flere moduler utover svindel og autentisering.