Hvordan velge en AML-plattform uten å kjøpe enda en silo

Mange AML-teknologisiloer skapes ikke av programvaren. De skapes tidligere, når et foretak behandler en AML-plattform som et compliance-verktøy snarere enn som en del av hvordan hele kunderelasjonene fungerer.

Mønsteret er velkjent. Compliance identifiserer et krav – onboarding, screening, risikoklassifisering, løpende overvåking – evaluerer leverandører og kjøper en løsning som kanskje gjør nøyaktig det som ble etterspurt. Ingen spør nødvendigvis hvordan den passer med salg, onboarding-operasjoner, kundeservice eller informasjon som allerede finnes andre steder. Kravet blir oppfylt. Driftsmodellen forbedres ikke nødvendigvis.

Spørsmålet de fleste foretak stiller under anskaffelsen er: hvilket AML-system trenger vi for å oppfylle dette kravet? Det mer nyttige spørsmålet er: hvordan oppfyller vi våre regulatoriske forpliktelser samtidig som vi gjør den samlede kundearbeidsflyten bedre? Disse to spørsmålene fører til svært forskjellige innkjøp.

Programvare følger organisasjonskartet. Kundene gjør det ikke.

En silo er ikke bare et system uten et API. Det dypere problemet er organisatorisk og oppstår lenge før noe bestemt stykke programvare. Foretak deler seg naturlig inn i avdelinger – salg, compliance, drift, finans, kundeservice – hver med sin egen ledelse, KPI-er og til slutt sine egne systemer. Etter hvert som foretaket vokser, hardner disse skillene, og anskaffelser begynner å speile organisasjonskartet: compliance kjøper compliance-programvare, salg kjøper et CRM, drift kjøper arbeidsflytverktøy. Hvert enkelt innkjøp, vurdert alene, er som regel rasjonelt. Det samlede resultatet er det ofte ikke.

Selskaper kjøper programvare i tråd med organisasjonskartet. Kundene opplever ikke selskapet i tråd med organisasjonskartet. Kunden opplever én bedrift; relasjonen bak kan være fordelt på fem avdelinger og fem systemer som knapt snakker med hverandre.

Et system blir en silo når informasjonen eller arbeidsflyten inni det ikke kan delta i den bredere relasjonen: synlig for compliance men ikke for det kommersielle teamet, samme kunde representert ulikt ulike steder, en endring fanget opp i én plattform som ikke utløser noe andre steder, informasjon tastet inn på nytt for hånd fordi ingenting er koblet sammen. En silo hindrer ikke bare informasjon i å komme inn. Den hindrer verdifull informasjon i å komme ut.

Informasjonen som er fanget i compliance kan ha betydning andre steder

Løpende overvåking kan avdekke at en kundes eierskap har endret seg, at en direktør har skiftet, eller at kunden har omklassifisert sin registrerte forretningsaktivitet. Dette har åpenbart compliance-relevans. Det kan også ha betydning for relasjonsansvarlig, som ellers ville gått inn i neste møte uvitende – i stedet for å åpne med «Jeg la merke til at eierstrukturen din endret seg nylig, hva betyr det for virksomheten?» Poenget er ikke at compliance eksisterer for å generere salgsmuligheter; det er at informasjon innhentet for ett legitimt formål kan ha bredere verdi andre steder, der det er hensiktsmessig å dele den. Den samme hendelsen kan være en compliance-utløser og nyttig kundeintelligens. En silo tvinger organisasjonen til å behandle den som bare én av disse – et spørsmål om gjennomtenkt informasjonsarkitektur, ikke et argument for å distribuere hvert eneste compliance-datapunkt til alle kommersielle brukere.

Foretak eksponerer disse samme siloene overfor kundene: informasjon som etterspørres to ganger, en relasjonsansvarlig som er uvitende om noe offentlig kjent om sin egen klient, separate portaler for deler av det som burde være én prosess. God teknologi vil ikke gjøre en svak relasjonsansvarlig til en fremragende en, men bedre informasjon kan hjelpe en rimelig god en til å møte godt forberedt. En godt integrert plattform bør få organisasjonen til å fremstå mer koordinert overfor kunden, ikke avsløre enda en intern avdeling. Kundene skal ikke måtte håndtere dine interne siloer på dine vegne.

Én plattform eller mange? Det avhenger av foretaket

Det er fristende å formulere dette som alt-i-ett kontra best-of-breed. Den debatten er i stor grad ved siden av poenget: riktig arkitektur avhenger av foretakets størrelse, kompleksitet og vekstfase, ikke av en generell preferanse for én modell.

For en mindre regulert virksomhet kan én plattform som håndterer store deler av kundens livssyklus være fullt ut rasjonelt – og kjøperen er ofte av en annen karakter, ikke bare av en annen størrelse. Den som kjøper kan være grunnleggeren, en managing partner, administrerende direktør eller en senior operativ leder, som ser på teknologien som en del av å drive virksomheten som helhet snarere enn som en avdelingsmessig compliance-beslutning – ofte fordi det ikke finnes noen separat compliance-avdeling til å ta den beslutningen. Denne personen er også personlig klar over at tid brukt på onboarding, dokumentinnsamling, KYC og gjennomganger er tid som ikke brukes på å generere inntekter eller betjene kunder – noe som kan gjøre en mindre bedrift mer i stand til å ta én samlet teknologibeslutning enn en større. Det gir liten mening å kjøpe seks leverandører for seks smale funksjoner i den størrelsesordenen; konsolidering er en fordel. Avhengig av marked og konfigurasjon kan IQON dekke en betydelig del av den livssyklusen direkte – onboarding, KYC/KYB, screening, risikoklassifisering og løpende overvåking, blant andre funksjoner. Den eksakte konfigurasjonen avhenger av markedet og kundens krav.

Ettersom foretak vokser, har anskaffelser en tendens til å bli mer avdelingsbasert – compliance kjøper for compliance, salg kjøper for salg, drift kjøper for drift – noe som er én av grunnene til at siloer oppstår i utgangspunktet. For en større organisasjon er flere spesialiserte systemer ofte uunngåelige og ønskelige. Det viktige spørsmålet er ikke hvor mange systemer et foretak kjører, men om disse systemene til sammen utgjør én driftsmodell eller en samling usammenhengende avdelingsarbeidsflyter. Faren er ikke å kjøpe flere systemer. Faren er å kjøpe systemer som låser foretaket inne i adskilte arbeidsflyter – og det er her vekst må planlegges for på forhånd. En kunde kan starte med å bruke IQON til mesteparten av kundens livssyklus, og senere ta i bruk et spesialist-CRM, en dedikert dokumentplattform eller egne analyseverktøy etter hvert som det vokser. Det bør ikke tvinge kunden til å erstatte IQON bare fordi det har vokst fra én modul: en kunde skal kunne vokse fra enkeltfunksjoner uten å måtte vokse fra selve plattformen. IQON er bygget modulært, med API-basert integrasjon, slik at informasjon kan bevege seg inn og ut etter hvert som den omkringliggende teknologien utvikler seg – uten å late som om enhver integrasjon er problemfri; hva en bestemt integrasjon krever er et rimelig spørsmål å stille enhver leverandør.

Den beste AML-demoen starter før skjermdelingen

Det er ingenting galt med at en leverandør viser produktet sitt tidlig og selvsikkert. Advarselssignalet er noe annet: en leverandør som aldri forlater standarddemoscriptet – som ikke spør meningsfullt om hvordan kjøperen arbeider i dag, hvor de reelle smertepunktene er, eller hvordan en ideell fremtidig prosess ville se ut, men rett og slett antar at sin forhåndsdefinerte arbeidsflyt bør bli kundens.

En bedre samtale starter et annet sted: hva gjør dere i dag – den reelle prosessen, ikke den idealiserte; hvor gjør det vondt – det manuelle arbeidet, regnearkene som binder sammen systemer som burde snakke med hverandre, arbeid utført av folk som er mer senioritet enn oppgaven krever; og, i en ideell verden, hvordan ville dere ønske at dette fungerte. Først da viser en god leverandør hva plattformen kan gjøre – ved å demonstrere kundens fremtidige prosess, ikke sin egen foretrukne. En god AML-demo bør starte med kjøperens arbeidsflyt, ikke leverandørens funksjonslist.

Dette er viktig fordi kjøpere jevnlig forveksler en omvei med et krav. En potensiell kunde beskrev en svært tilpasset risikoklassifiseringsmetodikk som ved første øyekast hørtes ut som et krevende teknisk krav. Videre utspørring avslørte at den faktisk ble kjørt i et regneark, fordi regnskapsførerne som håndterte den var komfortable i Excel og den eksisterende plattformen ikke hadde mulighet til å romme den. Det reelle kravet var aldri «vi må bruke Excel.» Det var «vi trenger et risikoklassifiseringsrammeverk fleksibelt nok til å gjenspeile vår metodikk.» En god leverandør hjelper med å skille det et foretak genuint må gjøre fra det det bare gjør fordi det nåværende systemet ikke gir noe annet valg – uten å hevde å forstå foretakets egen virksomhet bedre enn foretaket selv. Målet er heller ikke å digitalisere dagens prosess nøyaktig slik den er: foretak samler opp unødvendige steg av alle slags grunner, og å gjengi dem trofast er ikke suksess. En god leverandør er ikke en managementkonsulent, men bør forstå problemet godt nok til å vise hvor steg kan forenkles snarere enn videreføres uendret.

En håndfull spørsmål gjør mer anskaffelsesarbeid enn en lang sjekkliste: hvordan ville vår eksisterende prosess fungere inne i plattformen din, og hvor ville vi fortsatt trenge Excel eller e-post for å bygge bro? Utløser en relevant hendelse riktig arbeidsflyt, eller må noen legge merke til den? Det mest avslørende spørsmålet av alle: etter å ha kjøpt plattformen din, hvilke deler av denne prosessen vil vi fortsatt måtte administrere et annet sted?

Vis meg år fem

De fleste AML- og KYC-demonstrasjoner begynner med onboarding, av den åpenbare grunnen at det er der en ny kunde møter produktet for første gang. Men onboarding representerer kanskje noen timer innenfor en relasjon som varer i fem eller ti år, og en beslutning som i hovedsak er basert på hvor attraktiv den første reisen ser ut, besvarer feil del av spørsmålet. Ikke kjøp en AML-plattform bare basert på hvor godt den håndterer dag én – be den vise deg år fem.

Spør hva som skjer når et dokument utløper, eierskap eller en direktør endres, en gjennomgang forfaller, eller relasjonen avsluttes. Ta den enkleste varianten: en kunde identifiseres med et pass som utløper om atten måneder. Hva er det som faktisk varsler organisasjonen, atten måneder senere, om at noe må gjøres – og det ærlige svaret bør ikke være noens hukommelse, en kalenderpåminnelse eller håpet om at den opprinnelige medarbeideren fortsatt er der. Den samme logikken gjelder for alle livssyklushendelser, uten å hevde at hvert utløp har identiske regulatoriske konsekvenser. Og når noe fra tre år tilbake trenger forklaring, betyr plattformens evne til å vise hva som var kjent og besluttet på det tidspunktet svært mye – et poeng denne serien har dekket andre steder.

Kundevekst bør ikke kreve lineær vekst i manuelt compliance-arbeid

Regulatoriske forpliktelser forbruker menneskelig tid, og noe av det er riktig brukt – skjønn og ansvarlighet er ikke noe som bør automatiseres bort. Men en stor del av tiden rundt dette skjønnet er administrasjon: innhenting av informasjon, sporing av utløp, overvåking av endringer, utløsing av gjennomganger, sammenstilling av bevisene en beslutningstaker trenger. Det er den delen teknologi bør redusere, og god AML-teknologi bør bryte den lineære koblingen mellom antallet kunder et foretak betjener og mengden manuelt compliance-arbeid det krever.

Det rette resultatet for en kjøper er ikke «systemet vårt kan behandle flere kunder.» Det ligger nærmere: vi økte antallet kunder vi betjener vesentlig uten å øke compliance-bemanningen med noe i nærheten av samme rate – en form for løftestangseffekt med reell presedens andre steder i finanssektoren, der skalerbare driftsplattformer har latt foretak øke volumet uten tilsvarende vekst i bemanning. Det beste målet på automatisering er ikke hvor mange oppgaver en leverandør merker som «automatisert». Det er hvor mye mer virksomhet organisasjonen kan håndtere uten å tilsette tilsvarende manuell arbeidskraft.

Ingenting av dette betyr å fjerne mennesker fra de beslutningene som betyr noe. God automatisering bør fjerne repetitiv administrasjon, samle inn og strukturere data, overvåke for endringer, rute arbeid til riktig person, presentere det de trenger å se, og vedlikeholde historikken automatisk – slik at mennesket bruker forholdsmessig mer tid på skjønn og tvetydige saker, og mindre på administrasjon. Målet er ikke å automatisere compliance-skjønn. Det er å slutte å kaste bort compliance-skjønn på administrasjon.

Hva skjer når foretaket krysser en grense

Verden er ikke styrt av ett AML-regelverk. Ulike jurisdiksjoner har ulike krav, risikofaktorer og dokumentasjonsforventninger, og alt dette endrer seg over tid. En plattform bygget rundt én jurisdiksjons forutsetninger har en tendens til å gjøre hvert nytt marked til sin egen compliance-silo, drevet av den som tilfeldigvis kjenner det markedets regler best.

IQON er designet for en verden der regulatoriske krav varierer mellom jurisdiksjoner og utvikler seg over tid. Risikoklassifiseringsarkitekturen er designet for å støtte jurisdiksjonsensitive regulatoriske parametere ved siden av et foretaks egen metodikk og risikoappetitt. Den garanterer ikke compliance i alle jurisdiksjoner, kjenner ikke automatisk til og anvender ikke alle rettsregler globalt, og erstatter ikke et foretaks egne juridiske fortolkninger av hva som gjelder for det – det den er designet for å gjøre er å gi et foretak én driftsmodell som kan tilpasses jurisdiksjonelle forskjeller, snarere enn å kreve en full ombygging hver gang det går inn i et nytt land. Det virkelige spørsmålet for et internasjonalt aktivt foretak: kan én driftsmodell tilpasse seg på tvers av jurisdiksjoner, eller vil ekspansjon ganske enkelt produsere en ny silo per land?

Start med problemet, ikke funksjonslisten

Ingenting av dette er et argument for en sjekkliste. Den sterkeste versjonen av det er hva en god kjøper instinktivt ønsker å si til en leverandør: vi har et problem, kan du løse det – snarere enn å ankomme med tjuesju påkrevde funksjoner og spørre hvem som krysser av flest bokser. Funksjoner er viktige, men en prosess som starter med en funksjonssammenligning har allerede latt leverandørenes eksisterende produktstrukturer definere løsningen, før foretaket har beskrevet sitt eget problem ordentlig.

Den bedre prosessen starter med foretakets egen beskrivelse av seg selv: hvordan det fungerer i dag, hvor tid kastes bort, hvor kunder opplever friksjon, hvor informasjon blir fanget mellom avdelinger, og hva som ikke kan skaleres slik det er. Først da gir det mening å be en leverandør bevise at plattformen støtter den driftsmodellen – i år, og i år fem. Ikke start med å spørre hvilken leverandør som har den lengste funksjonslisten. Start med: dette er problemet vi har, kan du løse det. Bruk IQON til så mye av kundens livssyklus som genuint gir mening, og integrer det med hva som ellers med rimelighet bør forbli separat. Den beste AML-plattformen er ikke nødvendigvis den som gjør mest. Det er den som lar et foretak fungere som én organisasjon, snarere enn å skape enda ett sted der compliance bor alene.