> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Regles KYT i puntuació: velocitat i condicions

> Configura regles KYT amb Didit: condicions, finestres de velocitat i accions automàtiques. 1,000 al mes inclosos, després $0.001 cada una.

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.

[Creació d'una regla — Didit Academy](https://www.youtube.com/embed/Yhm63_n7HuU?start=474\&rel=0\&playsinline=1)

> [!NOTE]
>
> Les regles es poden gestionar des de la **Consola empresarial**, l'API de gestió i el MCP de Didit. Fes servir la consola quan una persona del teu equip de compliment hagi de revisar cada canvi; fes servir l'API o el MCP quan les regles es creïn i s'ajustin de manera programàtica, per exemple en migrar un conjunt de regles d'un altre proveïdor. Consulta la [referència de l'API](https://docs.didit.me/ca/management-api/transactions/rules-list.md) i la [guia per gestionar les regles mitjançant l'API i el MCP](https://docs.didit.me/ca/transaction-monitoring/rules-api.md). Les regles s'avaluen a cada transacció enviada mitjançant [`POST /v3/transactions/`](https://docs.didit.me/ca/management-api/transactions/create), i el resultat apareix a la matriu `rule_runs[]` de la transacció (consulta l'[esquema de resposta](https://docs.didit.me/ca/transaction-monitoring/response-schema.md)).

## 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ó](https://docs.didit.me/ca/management-api/transactions/rules-install.md), 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](https://docs.didit.me/ca/transaction-monitoring/rules-library.md).

| Paquet | Exemples |
| - | - |
| **Finances** | Detecció d'estructuració (entrada/sortida), grans transaccions individuals per sobre dels llindars de declaració |
| **AML/CTF** | Límits de volum acumulat, moviment ràpid d'entrada i sortida, coincidència de les contraparts amb les llistes de sancions, paraules clau sospitoses a la referència del pagament |
| **Detecció d'anomalies** | Alta velocitat d'entrada i sortida, reactivació de comptes inactius després de 12+ mesos d'inactivitat |
| **FATF** | Exposició a jurisdiccions d'alt risc de les contraparts i de les adreces dels subjectes |
| **Intel·ligència de dispositius** | Ús repetit d'una campanya de bonificacions des de la mateixa empremta digital del dispositiu, múltiples empremtes digitals de dispositiu per al mateix subjecte |
| **Prevenció del frau** | Multicompte mitjançant empremtes digitals de dispositiu compartides entre subjectes diferents |
| **Monitoratge cripto** | Exposició a serveis de mixer o ofuscació, adreces d'alt risc (darknet, sancionades, fons robats) |
| **Cribratge cripto** | Exposició d'alt risc a l'origen dels fons (>30%), diverses contraparts arriscades, rebuig automàtic per finançament del terrorisme o explotació infantil, retenció pendent de cribratge, marcatge de carteres amb puntuació de risc mitjana |
| **Joc responsable** | Ràfegues ràpides de dipòsits en finestres curtes |
| **Comerç electrònic** | Patrons de transacció específics del comerç electrònic |

## Fonts de les regles

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

| Font | Descripció |
| - | - |
| **Configuració predefinida** | Regles instal·lades de la biblioteca integrada de Didit. Tu tries quines configuracions predefinides (o quins paquets complets) instal·lar, i controles el mode de cada configuració predefinida instal·lada (`Active`, `Test`, `Disabled`). Les seves condicions i llindars són fixos: per modificar-ne un, crea una regla personalitzada. S'eliminen desinstal·lant-les, no pas esborrant-les. |
| **Personalitzat** | Regles creades pel teu equip des de la Consola empresarial. Tens el control total de les regles personalitzades: pots crear-les, editar-les i eliminar-les segons calgui. |

## Anatomia d'una regla

Cada regla consta de:

| Component | Descripció |
| - | - |
| **Títol i descripció** | Nom comprensible i explicació del que detecta la regla |
| **Categoria** | Agrupació lògica (p. ex., `finance`, `aml_ctf`, `crypto_monitoring`, `device_intelligence`) |
| **Mode** | `Active` (avaluació en directe), `Disabled` (s'omet) o `Test` (s'avalua, però els resultats no afecten la transacció) |
| **Mode d'avaluació** | `All` (cada condició ha de coincidir) o `Any` (almenys una condició ha de coincidir) |
| **Àmbit** | Limita les transaccions a les quals s'aplica la regla. Claus: `transaction_types`, `directions` (`INBOUND`/`OUTBOUND`), `action_types`. Buit o absent vol dir sense restricció |
| **Condicions** | Comprovacions a nivell de camp: comparen els camps de la transacció amb valors mitjançant operadors com `eq`, `lt`, `gte`, `in`, `contains_any`, `exists` |
| **Agregació** | Finestres de velocitat: agreguen transaccions històriques en un període (p. ex., recompte, suma o recompte de valors diferents en 1 hora, 7 dies, 30 dies) |
| **Accions** | Què passa quan es compleix la regla (vegeu més avall) |

## 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:

| Acció | `type` | Claus | Descripció |
| - | - | - | - |
| **Afegir puntuació** | `add_score` | `value` (enter, pot ser negatiu) | Afegeix punts a la puntuació de risc de la transacció. La puntuació acumulada de totes les regles coincidents determina si la transacció supera el llindar de revisió o el de denegació. |
| **Canviar estat** | `change_status` | `value` (`APPROVED`\|`IN_REVIEW`\|`DECLINED`\|`AWAITING_USER`, àlies `status`), `workflow_id` (àlies `remediation_workflow_id`) | Estableix directament l'estat de la transacció, independentment de la puntuació. `workflow_id` és obligatori quan `value` és `AWAITING_USER`; si s'omet, retorna `400`. |
| **Afegir etiquetes** | `add_tags` | `tag_uuid` o `tag_name` (un dels dos), `tag_color` | Etiqueta la transacció per a la categorització i el filtratge. Un `tag_uuid` d'una etiqueta existent, o un `tag_name` que es crea en el primer ús (es desa en majúscules); `tag_color` estableix el color hexadecimal d'una etiqueta de nova creació. |
| **Afegir nota** | `add_note` | `note` (àlies `value`) | Adjunta a la transacció una nota de text automàtica perquè l'analista tingui context. |
| **Afegir a una llista** | `add_to_list` | `list_id` | Afegeix el `vendor_data` del subjecte a una llista de bloqueig, una llista d'autorització o una llista personalitzada. |
| **Obrir cas** | `open_case` | `blueprint` (UUID de plantilla de cas, opcional), `grouping` (`by_applicant`\|`by_rule_and_applicant`), `attach_matched_transaction` (booleà) | Obre un cas d'investigació (o hi afegeix la transacció). Només s'aplica la primera acció `open_case` d'una regla. |

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](https://docs.didit.me/ca/transaction-monitoring/sdk-transaction-submission.md#accions-requerides-de-l’usuari).

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](https://docs.didit.me/ca/transaction-monitoring/settings.md#flux-de-treball-de-remediació).
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](https://docs.didit.me/ca/transaction-monitoring/wallet-ownership-widget.md).

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](https://docs.didit.me/ca/transaction-monitoring/sdk-transaction-submission.md#exemple-reverificació-biomètrica-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`.

> [!NOTE]
>
> Es pot utilitzar com a acció de remediació qualsevol tipus de flux de treball que no sigui KYB.
> Els fluxos d'Autenticació biomètrica (i els fluxos en què la coincidència facial s'executa abans de la verificació d'identitat) requereixen, a més, una cara de referència emmagatzemada del subjecte: un selfie de prova de vida aprovat, una foto del xip del passaport, un retrat del document o una cara inscrita manualment al perfil.
> Si no n'hi ha cap, se li demana a l'usuari que completi el flux de treball per defecte de la teva aplicació, que també inscriu la seva cara per a la propera vegada; una nota a la transacció registra la substitució.
> Només si tampoc existeix cap flux per defecte adequat s'omet la sessió, amb la nota que n'explica el motiu.

## 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):

| Configuració | Per defecte | Descripció |
| - | - | - |
| **Llindar de revisió** | 75 | Les puntuacions iguals o superiors a aquest valor activen `IN_REVIEW`. |
| **Llindar de denegació** | 500 | Les puntuacions iguals o superiors a aquest valor activen `DECLINED`. El valor per defecte (`500`) mai denega per puntuació. |

## 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](https://docs.didit.me/ca/integration/mcp/tools.md) i de qualsevol assistent d'IA connectat amb MCP).

> [tab] Consola
>
> 1. Ves a **Transaccions** > **Regles** a la consola
> 2. Fes clic a **Create Rule**
> 3. Defineix el títol, la descripció i la categoria de la regla
> 4. Defineix el **mode**: `Active` per executar-la en directe, o `Test` per avaluar-la sense afectar les transaccions
> 5. Tria el **mode d'avaluació**: `All` (cada condició ha de coincidir) o `Any` (almenys una)
> 6. Defineix l'**àmbit**: a quins tipus de transaccions o direccions s'aplica la regla
> 7. Afegeix **condicions**: comparacions de camps, com llindars d'import, codis de país o comprovacions de propietats personalitzades
> 8. Opcionalment, afegeix **agregació**: comprovacions de velocitat en una finestra de temps (recompte, suma, recompte de valors distints i més)
> 9. Defineix una o diverses **accions**: afegir puntuació, canviar l'estat, afegir etiquetes, afegir notes, afegir a una llista o obrir un cas
> 10. Desa i activa la regla

> [tab] API
>
> Crida [`POST /v3/transactions/rules/`](https://docs.didit.me/ca/management-api/transactions/rules-create) amb els mateixos camps: `title`, `category`, `mode`, `evaluation_mode`, `scope`, `conditions`, `aggregation`, `actions`. La referència completa de camps, operadors i accions es troba en aquesta pàgina, i [gestionar regles mitjançant l'API i MCP](https://docs.didit.me/ca/transaction-monitoring/rules-api.md) explica pas a pas el flux recomanat de crear, fer backtest i activar, incloent-hi la migració d'un conjunt de regles des d'un fitxer CSV exportat d'un altre proveïdor.

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/`](https://docs.didit.me/ca/management-api/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:

| Mètrica | Descripció |
| - | - |
| `count` | Nombre de transaccions que coincideixen amb els filtres en la finestra |
| `sum` | Total d'un `field` numèric (p. ex., `preferred_currency_amount`) en la finestra |
| `max` / `min` / `avg` | Valor més gran, més petit o mitjà d'un `field` numèric en la finestra |
| `distinct_count` | Nombre de valors únics d'un `field` (p. ex., empremtes digitals de dispositiu diferents) en la finestra (`unique_count` és un àlies acceptat) |

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](#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

| Patró | Com funciona |
| - | - |
| **Estructuració** | Recompte de transaccions del mateix subjecte en 30 dies >= 20, amb un `max` d'import per sota de \$10,000 en la mateixa finestra |
| **Alta velocitat** | Recompte de transaccions entrants del mateix subjecte en 7 dies >= 20 |
| **Entrada i sortida ràpides** | La transacció actual és sortint + recompte de transaccions entrants del mateix subjecte en 6 hores >= 1 |
| **Multicompte** | Recompte de valors distints de subjectes que comparteixen la mateixa empremta digital de dispositiu en 7 dies >= 3 |
| **Reactivació d'inactius** | Dies des de l'última transacció del subjecte >= 365, combinats amb un import >= \$1,000 |

## Catàleg de camps

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

| Camp | Descripció |
| - | - |
| `amount`, `currency` | L'import de la transacció i el codi de moneda |
| `preferred_currency_amount`, `default_currency_code` | Import convertit a la moneda preferida de la teva aplicació (si no hi és, es fa servir `amount_in_default_currency`) |
| `direction` | `INBOUND` o `OUTBOUND` |
| `action_type` | El teu tipus d'acció, p. ex. `withdrawal`, `deposit`, `bet` |
| `transaction_type` | `finance`, `kyc`, `travelRule`, `userPlatformEvent` |
| `payment_details` | Referència de pagament en text lliure (l'objectiu de `contains_any` per a les regles de paraules clau) |
| `score`, `severity` | La puntuació de risc actual i la severitat de la transacció |
| `subject_vendor_data`, `counterparty_vendor_data` | Els teus identificadors per a les dues parts |
| `subject_country`, `counterparty_country` | Codis de país de les parts (s'accepten tant ISO-2 com ISO-3; es normalitzen abans de la comparació) |
| `subject_device_fingerprint`, `counterparty_device_fingerprint` | Empremta digital del dispositiu o identificador persistent del dispositiu |
| `subject_browser_family`, `subject_browser_version`, `subject_platform`, `subject_accept_language`, `subject_session_age_ms` | Detalls del context del dispositiu (també està disponible `counterparty_browser_family`) |
| `subject_ip_address`, `subject_ip_country`, `counterparty_ip_address`, `counterparty_ip_country` | Context de xarxa |
| `subject_payment_method_type`, `subject_payment_method_country`, `subject_payment_method_fingerprint`, `subject_payment_method_account_id` | El mètode de pagament del subjecte (els mateixos quatre camps existeixen per a `counterparty_payment_method_*`) |
| `travel_rule_status`, `travel_rule_required`, `travel_rule_obligations_count` | Estat de la comprovació de Travel Rule |
| `counterparty_dd_status`, `counterparty_risk_level`, `counterparty_jurisdiction`, `counterparty_responsiveness` | Què saps del VASP contrapart amb què ha contactat l'intercanvi de Travel Rule: la teva decisió sobre aquest (`APPROVED`, `RESTRICTED`, `BLOCKED`), el seu nivell de risc (`LOW`, `MEDIUM`, `HIGH`; `HIGH` mentre el teu propi cribratge de contraparts estigui marcat), el seu país i la seva capacitat de resposta (`RESPONSIVE`, `UNRESPONSIVE`, `UNKNOWN`). Consulta [Diligència deguda de contraparts de Travel Rule](https://docs.didit.me/ca/transaction-monitoring/travel-rule.md#camps-de-regla-i-preconfiguracions) |
| `subject_days_since_previous_transaction` | Dies des de la transacció anterior d'aquest subjecte del mateix tipus (regles d'inactivitat) |
| `tags` | Els noms de les etiquetes de la transacció |
| `custom_values.<key>` | Qualsevol clau que hagis enviat a `custom_properties` en crear la transacció |

## Operadors de condició

Les regles admeten els següents operadors de comparació per a les condicions:

| Operador | Descripció | Exemple |
| - | - | - |
| `eq` / `ne` | Igual / diferent | `direction eq "OUTBOUND"` |
| `gt` / `gte` / `lt` / `lte` | Comparacions numèriques i de dates; mai no coincideixen si falta algun dels dos costats | `preferred_currency_amount gte 25000` |
| `in` / `not_in` | Pertinença a una llista (també s'accepta un únic valor escalar) | `counterparty_country in ["IRN", "PRK", "SYR"]` |
| `contains` / `not_contains` | Subcadena sense distinció de majúscules i minúscules dins d'un valor de text | `payment_details contains "refund"` |
| `contains_any` | Qualsevol de les cadenes d'una llista és una subcadena del camp, sense distinció de majúscules i minúscules | `payment_details contains_any ["terror", "weapon"]` |
| `regex` | El patró del valor coincideix amb el camp | `subject_vendor_data regex "^guest-"` |
| `fuzzy_match` | Similitud aproximada de cadenes; requereix un llindar `score` (0-100) a la condició | `counterparty_name fuzzy_match "Acme Corp"` amb `score: 85` |
| `exists` / `is_not_empty` / `is_not_null` | El camp és present (àlies; `value` s'ignora) | `subject_device_fingerprint exists` |
| `not_exists` / `is_empty` / `is_null` | El camp és absent o buit (àlies; `value` s'ignora) | `subject_ip_address is_empty` |

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`:

| `value_type` | Significat |
| - | - |
| `list` | `value` és un UUID de llista: les entrades de la llista de bloqueig, de la llista de permesos o de la llista personalitzada passen a ser el valor de comparació, de manera que una regla pot coincidir amb "contrapart a la meva llista de vigilància personalitzada". |
| `field` | `value` és una altra ruta de camp: la condició compara dos camps de la transacció, per exemple `subject_payment_method_account_id ne counterparty_payment_method_account_id`. |
| `relative_date` | `value` és una data relativa, per exemple `{"direction": "past", "unit": "days", "amount": 30}`, pensada per a camps de data com `txn_date`. |

### 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/`](https://docs.didit.me/ca/transaction-monitoring/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:

| Entitat | Tipus de llista de bloqueig | Què es comprova |
| - | - | - |
| **Usuari (sol·licitant)** | Llista de bloqueig d'usuaris | L'identificador `vendor_data` del sol·licitant |
| **Empresa** | Llista de bloqueig d'empreses | L'identificador `vendor_data` de l'empresa |
| **Adreça** | Llista de bloqueig d'adreces | El `account_id` dels mètodes de pagament amb cartera cripto |
| **Compte bancari** | Llista de bloqueig de comptes bancaris | El `account_id` dels mètodes de pagament per transferència bancària |
| **Adreça IP** | Llista de bloqueig d'adreces IP | L'adreça IP del context del dispositiu de la part (admet rangs CIDR) |
| **Empremta del dispositiu** | Llista de bloqueig d'empremtes de dispositiu | L'empremta del dispositiu o l'identificador persistent del dispositiu |

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

> [!NOTE]
>
> Les comprovacions de llistes de bloqueig s'executen abans de l'avaluació de les regles. Una entitat bloquejada sempre es rebutjarà, independentment de la configuració de les regles o dels llindars de puntuació.

## 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

> [card] [Enviament de transaccions](https://docs.didit.me/ca/transaction-monitoring/transactions.md)
>
> Com s'estructuren les transaccions per a l'avaluació de regles.

> [card] [Cribratge de criptomonedes](https://docs.didit.me/ca/transaction-monitoring/aml-screening.md)
>
> Resultats del cribratge de criptomonedes i com les utilitzen les regles predefinides.

> [card] [Configuració](https://docs.didit.me/ca/transaction-monitoring/settings.md)
>
> Configura els llindars de puntuació i els fluxos de treball de remediació.

> [card] [Referència de l'API](https://docs.didit.me/ca/management-api/transactions/create.md)
>
> Endpoint de l'API per crear transaccions.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.