Regles de decisió i llindars
Cada comprovació genera avisos, i tu decideixes què fa cada avís: aprovar, revisar o declinar. Aquesta correspondència és on realment viu el teu apetit de risc.
Cada pas fa correspondre els seus avisos amb una acció: aprovar, revisar o declinar. Un pas configurat per declinar atura el flux de treball - els passos posteriors mai s'executen, i no se't factura per ells. Això fa que l'ordre de les regles sigui alhora una decisió de risc i una decisió de cost.
#On es prenen realment les decisions
És temptador pensar en un flux de treball com "les comprovacions que executo". Les comprovacions només en són la meitat. L'altra meitat - i la que determina el teu percentatge d'aprovació - és què estan configurats per fer els avisos de cada comprovació.
- Cada node de funcionalitat porta els seus propis llindars i la seva pròpia decisió.
- Una comprovació pot ser obligatòria o opcional, cosa que ja és en si mateixa una decisió sobre qui passa.
- Una regla canviada arriba a les sessions noves un cop es desa el flux de treball.
Per a cada pas, cada avís que pot generar es correspon amb una de tres accions:
| Acció | Efecte |
|---|---|
| Approve (o ignorar) | L'avís queda registrat però no canvia el resultat |
| Review | La sessió passa a In Review perquè una persona decideixi |
| Decline | La sessió es declina i el flux de treball s'atura |
Aquesta correspondència és la teva política, expressada com a configuració.
#Una declinació atura el flux de treball
Aquest és el comportament que més sorprèn la gent, així que val la pena ser explícit: quan un pas declina, l'execució s'atura allà mateix. Els passos posteriors mai s'executen.
Dues conseqüències:
- Al resultat li faltaran comprovacions que esperaves. No han fallat - mai s'han executat. Una sessió declinada a la verificació d'identitat no tindrà cap prova de vida, cap coincidència facial, cap AML.
- No se't factura per elles. La facturació és per funcionalitat completada, així que un pas que mai s'ha executat no costa res.
#Fer servir l'ordre de les regles per controlar el cost
Com que una declinació atura el flux, l'ordre dels passos és una palanca de despesa. Posar una comprovació de risc barata davant d'un paquet car fa que el trànsit que mai anava a passar s'aturi abans de pagar per la part cara.
L'anàlisi de dispositiu i IP a 0,03 $ davant d'un flux complet de KYC és l'exemple estàndard: filtra, de manera barata, el trànsit que rebutjaries igualment.
El compromís és l'experiència d'usuari i els falsos positius. Els senyals de dispositiu i IP són les comprovacions més sorolloses que ofereix Didit - xarxes corporatives, NAT d'operadora, i navegadors al núvol posen usuaris genuïns darrere d'adreces compartides. Filtrar tot un flux basant-t'hi bloquejarà clients reals, així que envia'ls a review en lloc de declinar-los tret que hagis mesurat el teu propi trànsit.
#Regles que necessiten criteri, no automatització
Alguns avisos són inequívocs i haurien de declinar: una suma de comprovació MRZ fallida, un xip la signatura del qual no encadena amb el seu emissor, una cara a la teva llista de bloqueig. Aquestes són fallades d'integritat.
D'altres gairebé sempre són millors com a revisió:
- Coincidències parcials d'adreça en la prova d'adreça - els formats varien segons el país.
- Coincidències parcials de nom en la validació de bases de dades - les fonts oficials registren els noms de maneres diferents.
- Coincidències candidates d'AML de baixa confiança - els noms comuns en generen constantment.
- Una coincidència facial al límit - vegeu puntuacions i llindars de coincidència facial.
- Un avís de cara duplicada - que és frau per a un compte nou i normal per a un client que torna.
I algunes són fallades d'usabilitat que mereixen un reintent, no un veredicte: un xip NFC no llegit, una captura borrosa, un fotograma de càmera perdut.
#Polítiques d'edat
L'edat mínima i màxima es configuren per flux de treball, i l'acció davant d'una infracció és tria teva. MINIMUM_AGE_NOT_MET pot declinar directament, o enrutar-se a revisió si la teva política permet una excepció amb proves. Totes dues són legítimes; tria-ho deliberadament.
#Regles personalitzades sobre dades extretes
Més enllà de la correspondència per avís, pots escriure regles sobre les dades que un pas ha extret - per exemple, declinant quan un camp extret pren un valor concret. Dues coses a tenir en compte:
- La regla només pot actuar sobre dades que el pas realment ha produït. Si l'OCR no ha extret el camp, la regla no té res a avaluar.
- Una regla que declina continua aturant el flux de treball, amb les mateixes conseqüències que abans.
Si estàs construint una regla que activa una característica protegida, tracta-ho com una qüestió legal per al teu equip de compliment abans que com una qüestió d'enginyeria.
#Prova les regles, no només els passos
Els passos d'un flux de treball són fàcils de verificar a simple vista. Les seves regles no ho són - l'única manera de saber que un avís s'enruta on creus que ho fa és produir aquell avís.
El sandbox existeix per a això. Cada escenari força un avís concret, així que pots confirmar l'acció de cada regla de principi a fi: decline_document_expired, review_face_match_borderline, decline_aml_hit, review_poa_partial_match, i així successivament. Vegeu com provar en sandbox.
Prova el camí de review amb la mateixa cura que el de declinació. Una regla que enruta a revisió només és útil si algú realment treballa la cua, i la manera de saber si el teu procés de revisió funciona és fer passar-hi una sessió sintètica abans que hi hagi un client real esperant.
#Els canvis s'apliquen a les sessions noves
Editar un flux de treball no canvia retroactivament les sessions ja creades. Una sessió porta la configuració amb què es va crear, així que després d'un canvi de regla, prova amb una sessió nova en lloc de tornar a comprovar-ne una d'antiga.