Kuinka valita AML-alusta ostamatta uutta siiloa

Monet AML-teknologiasiiloista eivät synny ohjelmiston takia. Ne syntyvät jo aiemmin, kun yritys kohtelee AML-alustaa compliance-osaston työkaluna sen sijaan, että näkisi sen osana koko asiakassuhteen hoitamista.

Kaava on tuttu. Compliance tunnistaa vaatimuksen — asiakkaan vastaanottaminen, seulonta, riskiluokittelu, jatkuva seuranta — arvioi toimittajia ja hankkii ratkaisun, joka saattaa tehdä täsmälleen sen, mitä pyydettiin. Kukaan ei välttämättä kysy, miten se sopii yhteen myynnin, käyttöönottooperaatioiden, asiakaspalvelun tai muualla jo olevan tiedon kanssa. Vaatimus täyttyy. Toimintamalli ei välttämättä parane.

Useimmat yritykset kysyvät hankintavaiheessa: mitä AML-järjestelmää tarvitsemme tämän vaatimuksen täyttämiseksi? Hyödyllisempi kysymys on: miten täytämme sääntelyvelvoitteemme samalla kun parannamme koko asiakastyönkulkua? Nämä kaksi kysymystä johtavat hyvin erilaisiin hankintoihin.

Ohjelmisto seuraa organisaatiokaaviota. Asiakkaat eivät.

Siilo ei ole pelkästään järjestelmä ilman rajapintaa. Syvempi ongelma on organisatorinen, ja se edeltää mitä tahansa yksittäistä ohjelmistoa. Yritykset jakautuvat luonnostaan osastoihin — myynti, compliance, operaatiot, talous, asiakaspalvelu — joilla kullakin on oma johtonsa, mittarinsa ja lopulta omat järjestelmänsä. Yrityksen kasvaessa nämä jaot jäykistyvät, ja hankinta alkaa peilata organisaatiokaaviota: compliance ostaa compliance-ohjelmistoa, myynti ostaa CRM:n, operaatiot ostaa työnkulkutyökaluja. Jokainen hankinta erikseen arvioituna on yleensä järkevä. Yhdistetty lopputulos ei usein ole.

Yritykset ostavat ohjelmistoja organisaatiokaavionsa mukaan. Asiakkaat eivät koe yritystä organisaatiokaavionsa mukaan. Asiakas kokee yhden yrityksen; sen taustalla oleva suhde saattaa olla jaettuna viiden osaston ja viiden järjestelmän kesken, jotka tuskin kommunikoivat keskenään.

Järjestelmästä tulee siilo, kun sen sisällä oleva tieto tai työnkulku ei pysty osallistumaan laajempaan asiakassuhteeseen: näkyy compliancelle mutta ei kaupalliselle tiimille, sama asiakas on esitetty eri tavoin eri paikoissa, yhteen alustaan kirjautuva muutos ei käynnistä mitään muualla, tietoa syötetään käsin uudelleen koska mikään ei yhdisty. Siilo ei estä ainoastaan tiedon sisään pääsemistä. Se estää arvokkaan tiedon ulos pääsemistä.

Complianceen suljettu tieto voi olla merkityksellistä muuallakin

Jatkuva seuranta saattaa havaita, että asiakkaan omistusrakenne on muuttunut, johtaja on vaihtunut tai asiakas on luokitellut rekisteröidyn liiketoimintansa uudelleen. Tällä on selvästi merkitystä compliancen kannalta. Se voi myös merkitä asiakkuuspäällikölle, joka muutoin astuisi seuraavaan kokoukseen tietämättömänä — sen sijaan, että avaisi keskustelun sanomalla: "Huomasin, että omistusrakenteenne muuttui äskettäin — mitä se tarkoittaa liiketoimintanne kannalta?" Ajatuksena ei ole, että compliance olisi olemassa myyntivihjeiden tuottamista varten; kyse on siitä, että yhtä laillista tarkoitusta varten kerätyllä tiedolla voi olla laajempaa arvoa muualla, missä sen jakaminen on asianmukaista. Sama tapahtuma voi olla sekä compliance-laukaisin että hyödyllinen asiakastieto. Siilo pakottaa organisaation käsittelemään sitä vain toisena näistä — kyse on harkitusta tietoarkkitehtuurista, ei argumentista jokaisen compliance-tietopisteen jakamiseksi kaikille kaupallisille käyttäjille.

Yritykset paljastavat nämä samat siilojen reunat myös asiakkailleen: tietoja pyydetään kahdesti, asiakkuuspäällikkö ei tiedä jotain julkista omasta asiakkaastaan, erillisiä portaaleja osille siitä, minkä pitäisi olla yksi prosessi. Hyvä teknologia ei muuta heikkoa asiakkuuspäällikköä erinomaiseksi, mutta parempi tieto voi auttaa kohtuullisen hyvää saapumaan valmistautuneena. Hyvin integroitu alusta saisi organisaation näyttämään koordinoidummalta asiakkaan silmissä sen sijaan, että paljastaisi toisen sisäisen osaston. Asiakkaiden ei pitäisi joutua hallitsemaan sisäisiä siilojanne puolestanne.

Yksi alusta vai useita? Se riippuu yrityksestä.

On houkuttelevaa esittää tämä kaiken kattavan ratkaisun versus parhaiden erikoistyökalujen välisenä valintana. Tuo keskustelu on pitkälti sivuseikka: oikea arkkitehtuuri riippuu yrityksen koosta, monimutkaisuudesta ja kasvuvaiheesta, ei yleisestä mieltymyksestä johonkin malliin.

Pienemmälle säännellylle yritykselle yksi alusta, joka hoitaa suuren osan asiakkaan elinkaaresta, voi olla täysin järkevä valinta — ja ostaja on usein erilainen myös luonteeltaan, ei pelkästään kooltaan. Hankkija voi olla perustaja, toimitusjohtaja, vastuunalainen yhtiömies tai ylempi operatiivinen johtaja, joka tarkastelee teknologiaa osana koko liiketoiminnan pyörittämistä eikä osastotason compliance-päätöksenä — usein siksi, että erillistä compliance-osastoa ei ole tekemässä sitä päätöstä. Tämä henkilö on myös henkilökohtaisesti tietoinen siitä, että asiakkaiden vastaanottamiseen, asiakirjojen keräämiseen, KYC:hen ja tarkistuksiin käytetty aika on pois tulojen hankkimisesta tai asiakkaiden palvelemisesta — mikä voi tehdä pienemmästä yrityksestä kykenevän tekemään yhden, yhtenäisen teknologiapäätöksen paremmin kuin suurempi. Kuuden toimittajan ostaminen kuutta kapeaa toimintoa varten ei ole järkevää tässä mittakaavassa; konsolidointi on etu. Markkinasta ja kokoonpanosta riippuen IQON voi kattaa merkittävän osan tästä elinkaaresta suoraan — asiakkaan vastaanottaminen, KYC/KYB, seulonta, riskiluokittelu ja jatkuva seuranta muiden toimintojen ohella. Tarkka kokoonpano riippuu markkinasta ja asiakkaan vaatimuksista.

Yritysten kasvaessa hankinta pyrkii muuttumaan osastokeskeisemmäksi — compliance ostaa compliancelle, myynti ostaa myynnille, operaatiot ostaa operaatioille — mikä on yksi syy, miksi siiloja syntyy ensinnäkin. Suuremmalle organisaatiolle useat erikoistuneemmat järjestelmät ovat usein väistämättömiä ja toivottavia. Tärkeä kysymys ei ole, kuinka monta järjestelmää yritys käyttää, vaan muodostavatko nämä järjestelmät yhdessä yhden toimintamallin vai joukon erillisiä osastollisia työnkulkuja. Vaara ei ole useiden järjestelmien hankkiminen. Vaara on sellaisten järjestelmien hankkiminen, jotka sulkevat yrityksen erillisiin työnkulkuihin — ja tähän kasvu on suunniteltava etukäteen. Asiakas saattaa aloittaa IQONin käytön suurimmassa osassa asiakkaan elinkaarta ja ottaa myöhemmin käyttöön erikoistuneen CRM:n, erillisen asiakirja-alustan tai omia analytiikkatyökaluja kasvaessaan. Tämän ei pitäisi pakottaa korvaamaan IQONia vain siksi, että yksittäinen moduuli on käynyt ahtaaksi: asiakkaan pitäisi pystyä kasvamaan yksittäisten ominaisuuksien ohi joutumatta kasvamaan ulos koko alustalta. IQON on rakennettu modulaarisesti, API-pohjaisen integraation avulla, jotta tieto voi liikkua sisään ja ulos ympäröivän teknologian kehittyessä — ilman että teeskennellään jokaisen integraation olevan vaivaton; se, mitä tietty integraatio vaatii, on aiheellinen kysymys mille tahansa toimittajalle.

Paras AML-demo alkaa ennen näytön jakamista

Ei ole mitään vikaa siinä, että toimittaja esittelee tuotteensa varhain ja itsevarmasti. Varoitusmerkki on jotain muuta: toimittaja, joka ei koskaan poikkea vakiodemoskriptistä — joka ei kysele merkityksellisesti, miten ostaja työskentelee tänä päivänä, mitkä ovat todelliset kipupisteet tai millainen ihanteellinen tulevaisuuden prosessi näyttäisi, vaan yksinkertaisesti olettaa, että sen valmis työnkulku pitäisi omaksua sellaisenaan.

Parempi keskustelu alkaa toisin: mitä teet tänään — todellinen prosessi, ei idealisoitu versio; missä se sattuu — manuaalinen työ, laskentataulukot, jotka silloittavat järjestelmiä joiden pitäisi kommunikoida keskenään, työ jonota hoitavat tehtävään nähden liian kokemata henkilöt; ja miten haluaisit tämän toimivan ihannetilanteessa. Vasta sitten hyvä toimittaja näyttää, mihin alusta pystyy — esitellen asiakkaan tulevaisuuden prosessin, ei omaa suosikkityönkulkuaan. Hyvä AML-demo pitäisi aloittaa ostajan työnkulusta, ei toimittajan ominaisuusluettelosta.

Tämä on tärkeää, koska ostajat sekoittavat rutiininomaisesti kiertoratkaisun varsinaiseen vaatimukseen. Eräs prospekti kuvaili pitkälle räätälöityä riskiluokittelumenetelmää, joka kuulosti ensi kuulemalta vaativalta tekniseltä vaatimukselta. Lisäkysymykset paljastivat, että sitä ajettiin laskentataulukossa, koska sitä hallinnoineet kirjanpitäjät olivat tottuneita Exceliin eikä olemassa oleva alusta kyennyt tukemaan sitä. Todellinen vaatimus ei koskaan ollut "meidän täytyy käyttää Exceliä." Se oli "tarvitsemme riskiluokittelukehyksen, joka on riittävän joustava heijastamaan metodologiaamme." Hyvä toimittaja auttaa erottamaan sen, mitä yrityksen todella täytyy tehdä, siitä, mitä se tekee vain siksi, että nykyinen järjestelmä ei jätä muita vaihtoehtoja — väittämättä ymmärtävänsä yrityksen liiketoimintaa paremmin kuin yritys itse. Tavoitteena ei myöskään ole digitalisoida nykyprosessia sellaisenaan: yritykset keräävät tarpeettomia vaiheita mitä moninaisimmista syistä, eikä niiden uskollinen toistaminen ole menestys. Hyvä toimittaja ei ole liikkeenjohdon konsultti, mutta sen pitäisi ymmärtää ongelma riittävän hyvin osoittaakseen, missä vaiheita voidaan yksinkertaistaa sen sijaan, että ne siirretään eteenpäin muuttumattomina.

Muutama oikea kysymys tekee enemmän hankintatyötä kuin pitkä tarkistuslista: miten nykyinen prosessimme toimisi alustallanne, ja missä tarvitsisimme edelleen Exceliä tai sähköpostia silloittamaan aukkoja? Laukaiseeko relevantti tapahtuma oikean työnkulun, vai täytyykö jonkun huomata se? Kaikkein paljastavin kysymys: kun olemme ostaneet alustanne, mitä osia tästä prosessista meidän täytyy edelleen hallita jossain muualla?

Näytä minulle vuosi viisi

Useimmat AML- ja KYC-demonstraatiot alkavat asiakkaan ottamisesta, koska se on ilmeisesti kohta, jossa uusi asiakas ensi kertaa kohtaa tuotteen. Mutta asiakkaan ottaminen saattaa edustaa muutamaa tuntia suhteessa, joka kestää viisi tai kymmenen vuotta, ja päätös, joka perustuu pääasiassa siihen, miten houkutteleva tuo ensimmäinen polku näyttää, vastaa väärään osaan kysymystä. Älä osta AML-alustaa pelkästään sen perusteella, miten hyvin se hoitaa ensimmäisen päivän — pyydä sitä näyttämään vuosi viisi.

Kysy, mitä tapahtuu, kun asiakirja vanhenee, omistus tai johtaja vaihtuu, tarkistus tulee ajankohtaiseksi tai suhde päättyy. Otetaan yksinkertaisin versio: asiakas tunnistetaan passin avulla, joka vanhenee kahdeksantoista kuukauden kuluttua. Mikä todella kertoo organisaatiolle kahdeksantoista kuukauden kuluttua, että jotain pitää tehdä — ja rehellinen vastaus ei saa olla jonkun muisti, kalenterimuistutus tai toivo siitä, että alkuperäinen työntekijä on edelleen paikalla. Sama logiikka ulottuu kaikkiin elinkaaren tapahtumiin, väittämättä että jokaisella vanhenemisella on identtinen sääntelyllinen seuraus. Ja kun kolme vuotta vanhaa asiaa täytyy selittää, alustan kyky näyttää, mitä silloin tiedettiin ja päätettiin, on erittäin tärkeää — seikka, jota tässä sarjassa on käsitelty muualla.

Asiakaskasvun ei pitäisi edellyttää lineaarista kasvua manuaalisessa compliance-työssä

Sääntelyvelvoitteet kuluttavat ihmisten aikaa, ja osa siitä käytetään asianmukaisesti — harkintaa ja vastuullisuutta ei pidä automatisoida pois. Mutta suuri osa siitä harkinnan ympärillä olevasta ajasta on hallintoa: tietojen keräämistä, vanhentumisen seurantaa, muutosten tarkkailua, tarkistusten käynnistämistä, päätöksentekijän tarvitsemien todisteiden kokoamista. Se on osa, jota teknologian pitäisi vähentää, ja hyvän AML-teknologian pitäisi katkaista lineaarinen yhteys sen välillä, kuinka monta asiakasta yritys palvelee ja kuinka paljon manuaalista compliance-työtä se vaatii.

Oikea tulos ostajalle ei ole "järjestelmämme pystyy käsittelemään enemmän asiakkaita." Se on lähempänä: kasvoimme merkittävästi palveluumme asiakkaiden määrässä kasvattamatta compliance-henkilöstöä läheskään samassa suhteessa — eräänlainen vipuvaikutus, jolle on todellista ennakkotapausta muualla finanssipalveluissa, missä skaalautuvat toiminta-alustat ovat antaneet yrityksille mahdollisuuden kasvattaa volyymia ilman vastaavaa henkilöstön lisäystä. Paras automaation mittari ei ole se, kuinka monta tehtävää toimittaja leimaa "automatisoiduksi." Se on se, kuinka paljon lisäliiketoimintaa organisaatio pystyy käsittelemään ilman vastaavaa manuaalisen työn lisäystä.

Tämä ei tarkoita ihmisten poistamista tärkeistä päätöksistä. Hyvän automaation pitäisi poistaa toistuva hallinto, kerätä ja jäsentää tietoa, seurata muutoksia, ohjata työ oikealle henkilölle, nostaa esiin sen, mitä heidän täytyy nähdä, ja ylläpitää historiaa automaattisesti — jotta ihminen käyttää suhteellisesti enemmän aikaa harkintaan ja moniselitteisiin tapauksiin ja vähemmän hallintoon. Tavoitteena ei ole automatisoida compliance-harkintaa. Se on lopettaa compliance-harkinnan tuhlaaminen hallintoon.

Mitä tapahtuu, kun yritys ylittää rajan

Maailma ei toimi yhden AML-sääntökirjan mukaan. Eri lainkäyttöalueilla on eri vaatimukset, riskitekijät ja dokumentaatio-odotukset, ja kaikki muuttuu ajan myötä. Alusta, joka on rakennettu yhden lainkäyttöalueen oletusten ympärille, tekee jokaisesta uudesta markkinasta oman compliance-siilonsa, jota johtaa se, jolla sattuu olemaan paras tuntemus kyseisen markkinan säännöistä.

IQON on suunniteltu maailmaan, jossa sääntelyvaatimukset eroavat lainkäyttöalueittain ja kehittyvät ajan myötä. Sen riskiluokitteluarkkitehtuuri on suunniteltu tukemaan lainkäyttöaluekohtaisia sääntelyparametreja yrityksen oman metodologian ja riskinottohalun rinnalla. Se ei takaa vaatimustenmukaisuutta jokaisella lainkäyttöalueella, ei automaattisesti tunne ja sovella kaikkia maailman lakeja, eikä korvaa yrityksen omaa oikeudellista tulkintaa siitä, mitä siihen sovelletaan — sen tarkoituksena on antaa yritykselle yksi toimintamalli, joka pystyy mukautumaan lainkäyttöaluekohtaisiin eroihin pakottamatta rakentamaan kaikkea uudelleen joka kerta, kun se astuu uuteen maahan. Todellinen kysymys kansainvälisesti toimivalle yritykselle: voiko yksi toimintamalli joustaa lainkäyttöalueiden välillä, vai luoko laajeneminen yksinkertaisesti uuden siilon per maa?

Aloita ongelmasta, ei ominaisuusluettelosta

Tämä ei ole argumentti tarkistuslistaa vastaan. Sen vahvin muoto on se, mitä hyvä ostaja haluaa vaistomaisesti sanoa toimittajalle: meillä on ongelma, voitteko ratkaista sen — sen sijaan, että saavuttaisiin kaksikymmentäseitsemän vaaditun ominaisuuden kanssa ja kysyttäisiin, kuka rastittaa eniten ruutuja. Ominaisuudet ovat tärkeitä, mutta prosessi, joka alkaa ominaisuusvertailulla, on jo antanut toimittajien olemassa olevien tuoterakenteiden määritellä ratkaisun, ennen kuin yritys on kunnolla kuvannut omaa ongelmaansa.

Parempi prosessi alkaa yrityksen omasta kuvauksesta itsestään: miten se toimii tänään, missä aikaa hukataan, missä asiakkaat kokevat kitkaa, missä tieto jumittuu osastojen välillä ja mikä ei pysty skaalautumaan sellaisenaan. Vasta sitten on järkevää pyytää toimittajaa todistamaan, että sen alusta tukee kyseistä toimintamallia — tänä vuonna ja vuonna viisi. Älä aloita kysymällä, kenellä toimittajista on pisin ominaisuusluettelo. Aloita: tämä on ongelmamme, voitteko ratkaista sen. Käytä IQONia niin suuressa osassa asiakkaan elinkaarta kuin se aidosti on järkevää, ja integroi se kaikkeen muuhun, minkä pitäisi kohtuullisesti pysyä erillään. Paras AML-alusta ei välttämättä ole se, joka tekee eniten. Se on se, jonka avulla yritys voi toimia yhtenä organisaationa sen sijaan, että se luo vielä yhden paikan, jossa compliance asuu yksin.