Inženjering: integracija, model događaja i implementacija
Napor oko integracije ne leži u tome koliko krajnjih tačaka pozivate, već u tome koliko dobro model događaja odgovara vašem poslovanju. Truvali prihvata događaj i vraća ocjenu i odluku: čak i nemonetarni događaji prate potpuno isti put.
Sa inženjerske strane, pitanje je obično: koliko je posla potrebno da se ovaj sistem uklopi u naš postojeći tok? Odgovor manje zavisi od broja krajnjih tačaka, a više od toga koliko se model događaja usklađuje sa vašim poslovanjem.
Kako funkcioniše osnovni tok?
Vaša aplikacija šalje događaj, sistem ga procjenjuje i vraća rezultat: ocjenu (score), aktivirana pravila i odluku. Odluka se vraća dovoljno brzo da se može koristiti direktno unutar toka, jer zakašnjela odluka zapravo i nije odluka.
Događaj nije samo finansijska transakcija. Prijave na sistem, promjene uređaja, otpremanje dokumenata, promjene podešavanja i otvaranje naloga takođe su događaji i koriste se u pravilima na potpuno isti način. Ova razlika je ključna u praksi: obrasci poput preuzimanja naloga (account takeover) i zloupotrebe bonusa ne mogu se definisati bez nemonetarnih događaja.
Šta treba uzeti u obzir kod modela podataka?
| Tema | Šta to znači |
|---|---|
| Izolacija izvora podataka | Podaci iz različitih proizvoda ili filijala se čuvaju odvojeno, a pravila su ograničena na nivo izvora |
| Definicije agregacija | Broj, suma i prosjek za klijenta unutar određenog perioda su unaprijed definisani i na njih se referiše po nazivu u pravilima |
| Verzije pravila | Specifičan skup pravila i verzija koja je izvršena čuvaju se zajedno sa rezultatom svakog događaja |
| Polja identiteta | ID uređaja, IP adresa, e-mail i platni instrument su polja koja se koriste za izgradnju mreže odnosa |
| Bilježenje odluka | Prvobitna odluka se čuva, zajedno sa istorijom promjena ako se kasnije modifikuje |
Čuvanje verzije pravila uz događaj je revizorski zahtjev, ali je korisno i sa inženjerske tačke gledišta: omogućava praćenje koja je tačno promjena pravila uzrokovala promjenu u ponašanju.
Da li promjene pravila zahtijevaju implementaciju?
Ne. Pravila postoje kao podaci, a ne kao kod. To znači da timovi za usklađenost (compliance) i sprječavanje prevara mogu mijenjati pravila bez čekanja na inženjerski red, čime se trajno smanjuje opterećenje inženjera. Struktura pravila je detaljno opisana na stranici pokretač pravila i scenarija.
Uticaj promjene pravila na istorijski saobraćaj može se izmjeriti prije puštanja u rad; stranica simulacija pravila i backtesting to detaljnije objašnjava.
Gdje se pokreće?
Implementacija se može izvršiti na sopstvenoj infrastrukturi organizacije. Ovo nije samo stvar izbora, već i regulatorni zahtjev u određenim sektorima: podaci nikada ne napuštaju organizaciju, logovi ostaju na vašim sistemima, a revizorski trag se može slati na odvojenu destinaciju. Detalji se nalaze na stranici on-premise implementacija.
Autorizacija i pristup
Model autorizacije pokriva maker/checker podjelu, politike odobravanja, odluke sa više potpisa i delegiranje ovlašćenja. Logovi pristupa se čuvaju u neizmjenjivom obliku i mogu se upisivati na odvojenu destinaciju. Detalji se nalaze na stranici maker/checker, autorizacija i revizorski trag.
Odakle početi?
Obično se počinje sa jednim tokom: onom tačkom koja uzrokuje najviše gubitaka ili generiše najviše upozorenja. Šalju se događaji za taj tok, pravila se pokreću u simulaciji, a rezultati se porede sa vašim postojećim sistemom. Ako je poređenje zadovoljavajuće, donošenje odluka se integriše u tok uživo.
Odgovarajuće perspektive timova detaljno su opisane na stranicama za timove za prevare i rizik i timove za usklađenost.
Česta pitanja
- Kako funkcioniše osnovna integracija?
- Vaša aplikacija šalje događaj, a sistem vraća ocjenu (score), aktivirana pravila i odluku. Odluka se vraća dovoljno brzo da se može koristiti direktno unutar toka.
- Da li se šalju samo finansijske transakcije?
- Ne. Prijave na sistem, promjene uređaja, otpremanje dokumenata, promjene podešavanja i otvaranje naloga takođe su događaji i koriste se u pravilima na potpuno isti način.
- Da li će se podaci iz različitih proizvoda pomiješati?
- Ne. Izvori podataka se čuvaju odvojeno, a pravila se mogu ograničiti na nivo izvora.
- Kako se definišu agregacije?
- Broj transakcija, suma i prosjek za klijenta unutar određenog perioda su unaprijed definisani i na njih se referiše po nazivu u pravilima.
- Da li promjene pravila zahtijevaju implementaciju?
- Ne. Pravila postoje kao podaci, a ne kao kod; timovi za usklađenost i sprječavanje prevara mogu mijenjati pravila bez čekanja na inženjerski red.
- Kako pronaći izvor promjene u ponašanju?
- Specifičan skup pravila i verzija koja je izvršena čuvaju se zajedno sa rezultatom svakog događaja, što omogućava praćenje koje je pravilo uzrokovalo promjenu.
- Gdje se hostuje implementacija?
- Može se hostovati na sopstvenoj infrastrukturi organizacije. Podaci nikada ne napuštaju organizaciju, logovi ostaju na vašim sistemima, a revizorski trag se može slati na odvojenu destinaciju.
- Odakle je najbolje početi?
- Sa jednim tokom koji uzrokuje najviše gubitaka ili generiše najviše upozorenja. Šalju se događaji za taj tok, pravila se pokreću u simulaciji, a rezultati se porede sa vašim postojećim sistemom.