Aloitimme tekemällä käytäntömoottorin mekaniikasta eksplisiittistä domain learningin kautta. Käytännöt tässä kontekstissa yhdistävät ehdot käyttäytymisen indikaattoreille, kuten laitteen sormenjäljelle, sijaintimuutokselle, kulutusnopeudelle ja aiemmalle epäonnistumishistorialle tuloksiin, kuten sallimiseen, estämiseen tai vahvistetun tunnistautumisen laukaisemiseen. Olemassa oleva käyttöliittymä esitti nämä säännöt tietokantanäkyminä ja konfigurointitaulukoina. Se ei vastannut sitä, miten analyytikot päättelevät petosmalleja tai miten he selittävät päätöksiä sisäisille tarkastustiimeille.

Työpajojen kautta Callsignin tuote-, insinööri- ja turvallisuusasiantuntijoiden kanssa Sandbox Experiments -vaiheen aikana kartoitimme olemassa olevat sääntörakenteet, petosskenaariot, jotka niiden täytyi kattaa, ja kohdat, joissa konflikteja tai aukkoja ilmeni. Tämä kartoitusharjoitus johti selkeään erotteluun petostentunnistusmallin, joka pisteyttää tapahtumat, ja käytäntötason välillä, joka soveltaa kynnysarvoja, yliajoja ja työnkulkupäätöksiä. Työstä tuli UX-suunnittelua tekoälyjärjestelmille, joissa käyttöliittymä kontrolloi miten mallin tuotokset virtaavat tosielämän toimintoihin.

Siitä määrittelimme informaatioarkkitehtuuri yritysturvallisuudelle, joka käsitteli käytäntöä keskeisenä objektina. Jokainen käytäntö niputtaa ehdot, toiminnot, historian ja linkit liittyviin sääntöihin. Analyytikot voivat seurata käytäntöä määrittelystä arviointiin poistumatta kontekstista. Päätökset tallennetaan tavalla, joka tukee tarkastuskatselmuksia ja sääntelytarkistuksia liittyen SCA:han, PCI DSS:ään ja sisäiseen hallintoon. Validoimme tämän rakenteen varhaiset versiot Callsignin tiimien kanssa käyttäen ytimekkäitä skenaarioita abstraktien kaavioiden sijaan, ja säädimme heidän palautteensa perusteella.

Arkkitehtuurin ollessa paikallaan suunnittelimme uudelleen analyytikkojen käyttäjäpolut vastaamaan sitä, miten petostiimit todella ajattelevat tapauksen läpi. Aiempi kokemus pakotti käyttäjät hyppimään konfigurointinäyttöjen, referenssidokumenttien ja datataulukoiden välillä, kun he halusivat säätää yhtä sääntöä. Korvasimme tämän käytäntökeskeisellä prosessilla. Analyytikot tunnistavat skenaarion, avaavat relevantin käytäntösetin, säätävät ehtoja kontekstissa ja näkevät välittömästi missä kohtaa työnkulkua muutos koskee.

Keskeisenä vuorovaikutuskonseptina oli kolmen eleen malli, joka suunniteltiin petosanalyytikoille. Analyytikot vetävät luodakseen tai sijoittaakseen solmuja uudelleen työnkulussa, klikkaavat avatakseen ja muokatakseen sääntöparametreja suoraan näkymässä ja piirtävät yhteyden linkittääkseen solmuja ja määritelläkseen järjestyksen. Nämä eleet ovat johdonmukaisia koko työkalussa, mikä pitää oppimisvaivan alhaisena käyttäjille, jotka tulevat riski- tai compliance-taustoista tuotetaustojen sijaan.

Meidän oli myös tehtävä laajuuskompromisseja tension-driven reasoning -menetelmän kautta. Ensimmäiseen julkaisuun priorisoimme politiikkojen luomisen, konfliktien näkyvyyden ja vaikutuksen selittämisen edistyneiden yhteistyöominaisuuksien tai täydellisten versiohistorianäkymien sijaan. Tämä päätös heijasti välitöntä tavoitetta tehdä demoista riski- ja turvallisuustiimien kanssa suurissa pankeissa tehokkaita ja uskottavia. Varhainen sisäinen testaus Callsignin analyytikoiden kanssa vahvisti, että uudet journeyt vähensivät aikaa, joka kului yleisen petosskenaarin ilmaisemiseen työkalussa, ja tekivät selityksistä asiakaspuhelujen aikana suoraviivaisempia.

Konfigurointi yksinään ei riittänyt. Callsign tarvitsi tavan, jolla analyytikot ja pankkien sidosryhmät voivat ymmärtää, mitä tietty politiikkajoukko tekisi realistisissa skenaarioissa. Loimme arviointitilan, jossa käyttäjät määrittelevät simulaatiokontekstin käyttämällä luonnollisen kielen tyylin suodattimia, kuten asiakassegmentti, maantiede tai transaktiotyyppi. Järjestelmä ajaa sitten nämä asetukset petostentunnistusmallin ja politiikkamoottori läpi ja esittää tulokset keskittyneessä analyyttisessä näkymässä.

Arviointinäkymä on keskeinen käyttäjäkokemukselle riskienhallintatyökaluissa, koska se sulkee silmukan konfiguroinnin ja vaikutuksen välillä. Analyytikot voivat nähdä, kuinka usein skenaario johtaisi automaattiseen hyväksyntään, vahvistettuun tunnistautumiseen tai estoon, ja voivat tarkistaa, pääsisivätkö korkean riskin tapaukset läpi. Tehdäksemme tämän tulkittavaksi luotimme datavisualisointiin pankkijärjestelmille, jotka toteutettiin D3:lla, käyttäen graafia ja virtauskuvauksia, jotka korostavat missä liikenne keskittyy ja missä käytännöt luovat pullonkauloja.

Pidimme konfiguroinnin ja arvioinnin välisen suhteen erittäin selkeänä. Käytäntöjä muokataan aina konfigurointiympäristössä, ja arviointiympäristö käyttää näitä määrityksiä antamatta käyttäjien muuttaa niitä suoraan paikallaan. Tämä suojakaide välttää seuraamattomat muutokset analyysin aikana. Käytimme evidenssiperustettua UX:ää tekoälylle hioaksemme arviointiprosessia, havainnoimalla miten analyytikot tulkitsivat kaavioita ja missä virhetulkintoja tapahtui, ja yksinkertaistimme sitten tunnisteita ja vuorovaikutuksia vastaavasti. Tuloksena on kontrolloitu mutta joustava silmukka, jossa analyytikot voivat testata, säätää ja perustella käytäntöstrategioita paljastamatta mallin sisäisiä rakenteita.

Ensimmäisistä viikoista lähtien käsittelimme jokaista näyttöä osana design systemiä yhden kerran tehtävän artefaktin sijaan Concept Convergence -vaiheen aikana. Järjestelmä kattaa työnkulun rakentamisen, käytäntöjen hallinnan, arviointinäkymät ja tukevan navigointirakenteen. Jokaisella komponentilla on dokumentoidut tilat, vuorovaikutussäännöt ja käyttöohjeet. Tästä perustasta tuli design system pankkituotteille, joka auttaa Callsignia ylläpitämään johdonmukaisuutta uusissa turvallisuusominaisuuksissa ja tulevissa moduuleissa.

Teknisellä puolella teimme yhteistyötä varhain front end -tiimin kanssa. Käytäntö- ja työnkulkukomponentit mallinnettiin React-yksikköinä, joita voidaan yhdistää monimutkaisempien näyttöjen luomiseksi ilman duplikaatiota. Esimerkiksi sama käytäntöyhteenvetomoduuli esiintyy konfigurointilistoissa, työnkulkukanvaasissa ja arviointituloksissa johdonmukaisella toimintasopimuksella. D3-pohjaiset visualisoinnit sijaitsevat omissa React-säiliöissään, joten asettelu- ja renderöintivastuut on selkeästi erotettu, mikä tukee suorituskyvyn optimointia suuremmille dataseteille.

Strukturoimme tuotokset sopimaan heidän kehitysprosessiinsa Implementation Partnership -vaiheen aikana. Spesifikaatiot seurasivat heidän olemassa olevan työn rakennetta Gitissä ja Confluencessa, ja osallistuimme säännöllisiin sessioihin insinöörien kanssa ratkaistaksemme edge caset ennen kuin ne saavuttivat toteutusvaiheen. Noin kahdeksan viikon jälkeen projekti saavutti vakaan tilan. Uudet työnkulut ja käytäntöjen hallintakäyttöliittymät olivat valmiita yritysdemoihin ja design system oli riittävän valmis ohjaamaan jatkokehitystä sisäisesti. Callsignin omat suunnittelijat käyttivät myöhemmin tätä järjestelmää pohjana lisämoduuleille petoksen ja tunnistautumisen ulkopuolella.