Regles KYT i puntuació: velocitat i condicions

Cada transacció enviada a Didit s’avalua segons totes les regles actives de la teva aplicació. Les regles defineixen condicions, comprovacions de velocitat i accions que determinen l’estat final i la puntuació de la transacció. Aquest capítol de la lliçó del motor de regles antifrau de Didit Academy continua amb la creació d’una regla. La lliçó del motor de regles de Didit Academy mostra com es crea una regla a partir del minut 7:54: activador, condicions, accions i puntuació, i després les proves retrospectives abans de desplegar-la.

​

Paquets de regles integrats

Didit ofereix una biblioteca de regles preconfigurades que cobreix tipologies normatives habituals. Instal·la les configuracions predefinides (o els paquets complets) que vulguis des de la biblioteca - a la consola, mitjançant l’API d’instal·lació, o amb les eines del MCP - i controla el mode de cada configuració predefinida instal·lada. Per al catàleg complet de totes les regles predefinides, amb llindars i accions, consulta la Biblioteca de regles.

​

Fonts de les regles

Cada regla té un source que indica qui la gestiona:

​

Anatomia d’una regla

Cada regla consta de:

​

Accions

Quan una regla coincideix amb una transacció, s’executen una o més accions. Cada regla pot tenir diverses accions, que s’apliquen totes alhora: La majoria de regles predefinides combinen Afegir puntuació amb Canviar estat. Per exemple, una regla de contrapart sancionada afegeix 90 punts a la puntuació i denega la transacció immediatament.

​

Requerir verificació de l’usuari (AWAITING_USER)

Una acció Canviar estat → AWAITING_USER fa més que establir un estat: Didit crea automàticament una sessió de verificació allotjada per al subjecte de la transacció (el mateix vendor_data) en el moment que s’activa la regla. La sessió es retorna al bloc action_required de la transacció (i a l’objecte remediation) en la resposta de creació i en totes les lectures posteriors, així com en tots dos webhooks de transacció, de manera que pots redirigir l’usuari immediatament; consulta accions de l’usuari requerides. Les regles personalitzades han d’indicar el flux de treball a la pròpia acció (workflow_id): tant el generador de regles de la consola com l’API de regles ho requereixen. Les regles de la biblioteca integrada no porten flux de treball; per a elles, el flux de la sessió es resol en aquest ordre:

1. El flux de treball de remediació configurat a la teva configuració de transaccions.
2. El flux d’Autenticació biomètrica de la teva aplicació, quan el subjecte ja té una cara de referència emmagatzemada d’una verificació aprovada.
3. El flux de treball per defecte de la teva aplicació.

Això vol dir que les regles de la biblioteca AWAITING_USER sempre generen una sessió accionable des del primer moment: una verificació biomètrica reforçada per als usuaris que ja has verificat, i una verificació completa en la resta de casos. Les transaccions de Travel Rule queden excloses d’aquest recurs automàtic: la seva espera AWAITING_USER serveix per demostrar la titularitat de la cartera, que té el seu propi flux. L’opció més sòlida per a transaccions d’alt risc és un flux d’Autenticació biomètrica: com que el subjecte és l’usuari que ja has verificat amb KYC, Didit reutilitza la cara de referència verificada de la seva alta (el selfie de prova de vida aprovat, la foto del xip del passaport o el retrat del document). L’usuari només es fa un selfie en directe, i Didit executa una prova de vida i una coincidència facial 1:1 amb la identitat que va obrir el compte. Les credencials robades, els OTP obtinguts per phishing i els intercanvis de SIM no superen aquest control. Guia completa: pas a pas de biometria reforçada per a una retirada d’alt valor. Quan la sessió arriba a una decisió, la transacció la segueix automàticament i s’activa un webhook transaction.status.updated: una sessió aprovada aprova la transacció (decision_reason_code: user_action_approved), una sessió denegada la denega (user_action_declined), i una sessió que acaba en revisió envia la transacció a IN_REVIEW (user_action_in_review). Una sessió caducada o abandonada manté la transacció a AWAITING_USER.

​

Puntuació

Quan una transacció coincideix amb una o més regles, les puntuacions es combinen:

1. Cada coincidència de regla contribueix a la puntuació de risc global de la transacció mitjançant l’acció add_score.
2. La puntuació final determina l’estat de la transacció segons els llindars de puntuació de la teva aplicació.
3. Si alguna regla té una acció change_status, aquest estat s’aplica directament; DECLINED sempre té prioritat.

Llindars de puntuació per defecte (configurables a la consola):

​

Creació de regles personalitzades

Les regles personalitzades es poden crear des de la Consola empresarial o mitjançant la API de gestió (també accessible des de Didit MCP i de qualsevol assistent d’IA connectat amb MCP). Les regles en mode Active tenen efecte immediat per a totes les transaccions noves. Els títols són únics per aplicació.

​

Proves retrospectives

Abans d’activar una regla, pots validar-la amb dades històriques:

• Posa una regla en mode Test: la regla s’avalua en cada transacció nova, però els resultats no afecten l’estat ni la puntuació de la transacció. Les estadístiques d’execució (nombre de coincidències, entitats afectades) s’acumulen perquè puguis avaluar l’impacte abans de posar-la en funcionament en directe.
• Usa la funcionalitat de proves retrospectives (a la consola o mitjançant POST /v3/transactions/rules/backtest/) per avaluar retroactivament les condicions i l’agregació d’una regla sobre les transaccions d’un període determinat. El backtest retorna el nombre de transaccions avaluades i coincidents, i les entitats afectades, sense modificar cap dada històrica. Envia els mateixos conditions, aggregation, evaluation_mode i scope que la regla que vols activar: un àmbit omès vol dir que no hi ha restricció, de manera que el backtest comptaria transaccions que la regla desada ignora.

​

Finestres de velocitat (agregació)

Les regles de velocitat agreguen dades històriques de transaccions en un període de temps per detectar patrons que les comprovacions d’una sola transacció no detectarien: Cada agregació especifica:

• Una finestra de temps: <N>m (minuts), <N>h (hores) o <N>d (dies), p. ex. 30m, 6h, 7d, 30d. Atenció: m són minuts, no mesos.
• Filtres per acotar quines transaccions històriques s’inclouen. Les claus són rutes de camps del catàleg de camps. El valor especial "__current__" es resol com el valor del mateix camp en la transacció avaluada (p. ex., "subject_vendor_data": "__current__" limita la finestra al mateix subjecte), i un valor de llista significa pertinença. Els filtres només comparen per igualtat o pertinença: no hi ha cap filtre lt ni gte, de manera que un rang com transaccions per sota de 10,000 no es pot expressar amb un filtre. Posa el rang a la mètrica (max per sota de 10,000, min per sobre de 1,000) i recorda que una condició restringeix la transacció avaluada, mai la finestra.
• Un operador i un llindar (eq, ne, gt, gte, lt, lte en relació amb value, p. ex. recompte >= 20)

​

Patrons d’exemple

​

Catàleg de camps

Les condicions i els filtres d’agregació fan referència als camps de la transacció mitjançant el seu camí:

​

Operadors de condició

Les regles admeten els següents operadors de comparació per a les condicions: Tots els altres operadors necessiten un value no buit, i l’API respon 400 si no n’hi ha cap. contains, not_contains i regex accepten una única cadena, no una llista ni un objecte; contains_any accepta una llista de cadenes.

​

Tipus de valor de la condició

Un value_type opcional a una condició canvia la manera com s’interpreta value:

​

Condicions agrupades

Una llista plana de condicions es combina segons el evaluation_mode de la regla (ALL/ANY). Per a lògica mixta, assigneu a les condicions un group_index: les condicions amb el mateix índex formen un grup, group_logic (AND/OR, per defecte AND) combina les condicions dins d’un grup, i groups_logic a la primera condició (AND/OR, per defecte OR) combina els resultats dels grups. Quan alguna condició porta un group_index, l’avaluació agrupada substitueix evaluation_mode.

​

Referència a propietats personalitzades

Cada clau enviada a l’objecte custom_properties de POST /v3/transactions/ es desa a la transacció com a custom_values i es pot fer servir a les condicions amb la ruta de camp custom_values.<key>. Per exemple, una transacció enviada amb "custom_properties": {"channel": "mobile_app"} coincideix amb la condició custom_values.channel eq "mobile_app". Tots els operadors anteriors funcionen amb propietats personalitzades, i també es poden comparar amb altres camps o fer servir en filtres de velocitat. A la Console, el constructor de regles mostra automàticament, al selector de camps de la condició i sota Propietats personalitzades, les claus observades en transaccions rebudes recentment. També podeu fer referència a una clau abans que cap transacció la porti: trieu Introdueix una propietat personalitzada al mateix grup i escriviu la clau exactament com la envia la vostra integració (les claus distingeixen majúscules i minúscules). La regla simplement s’avalua com a no coincident fins que arribin transaccions amb aquesta clau.

​

Rebuig automàtic per llista de bloqueig

Abans d’avaluar cap regla, Didit comprova les entitats de la transacció amb les llistes de bloqueig de la vostra aplicació. Si es troba qualsevol coincidència, la transacció es rebutja immediatament i les regles no s’avaluen. Es comproven les entitats següents: Quan es produeix una coincidència amb una llista de bloqueig:

• L’estat de la transacció passa a DECLINED
• El motiu de la decisió passa a ser blocklisted
• Es crea un registre d’activitat per al seguiment d’auditoria

​

Cribratge de transaccions

Didit s’integra amb proveïdors externs d’anàlisi AML i de blockchain per enriquir les transaccions amb informació de risc. Quan s’envia una transacció, el sistema pot:

• Cribrar les contraparts contra bases de dades globals de sancions i llistes de vigilància
• Avaluar les adreces de cartera (per a transaccions cripto) amb dades d’intel·ligència de blockchain, incloent l’exposició a mixers, les connexions amb entitats sancionades i les interaccions amb serveis d’alt risc
• Comprovar l’estat AML del sol·licitant creuant l’usuari vinculat a la transacció amb els resultats més recents del seu cribratge AML

Els resultats del cribratge s’adjunten a la transacció i entren en el càlcul de la puntuació del motor de regles. Si una contrapart o una cartera coincideix amb una llista de sancions, la regla corresponent marca o rebutja automàticament la transacció.

​

Passos següents