Creació d'un flux de treball SAR sense una eina de gestió de casos independent (CA)

Una regla que s'activa és la part fàcil. El que passa després —l'alerta, la investigació, l'escalada, la decisió de presentar un Informe d'Activitat Sospitosa (SAR)— és on resideixen la majoria de les operacions de compliment i on s'amaga la major part del cost. La configuració típica uneix tres coses: un proveïdor de monitorització que produeix alertes, una eina de gestió de casos separada que conté la investigació i un procés SAR manual que sovint acaba en un full de càlcul i un PDF. Les dades es tornen a introduir entre sistemes, la pista d'auditoria es fragmenta i els analistes passen el dia canviant de pestanya.

L'API de Monitorització de Transaccions de Didit inclou tot el flux de treball en un sol producte. Quan s'activa una regla, s'obre una alerta; les alertes s'agrupen en casos; s'assignen analistes; i el SAR es presenta des de la mateixa consola on es va generar l'alerta. No hi ha cap eina de casos separada per llicenciar, integrar o conciliar, i les transaccions que l'alimenten costen 0,02 $ cadascuna.

Aquesta guia recorre el flux de treball des d'una regla activada fins a un SAR presentat.

Punts clau

• Les alertes s'obren automàticament quan s'activa una regla i passen per un cicle de vida definit: OPEN (oberta), INVESTIGATING (investigant), AWAITING_USER (esperant usuari), PENDING_SAR (SAR pendent), SAR_FILED (SAR presentat), RESOLVED (resolta), DISMISSED (descartada).
• Els casos agrupen alertes relacionades, tenen prioritat i gravetat, i fan un seguiment d'una investigació a través dels estats OPEN (obert), UNDER_REVIEW (en revisió), AWAITING_USER (esperant usuari), ON_HOLD (en espera) i RESOLVED (resolt).
• S'assignen analistes a les alertes i els casos, de manera que la propietat i el rendiment són mesurables.
• La presentació de SAR viu a la mateixa consola que l'alerta; sense exportar a una eina separada, sense dades tornades a introduir.
• El camí AWAITING_USER permet a un analista retornar una alerta a l'usuari per a la seva remediación en lloc de resoldre-la manualment.
• 0,02 $ per transacció, sense mínims. La detecció AML d'una part marcada es factura per separat a 0,20 $.

Què fa el flux de treball de gestió de casos

La monitorització de transaccions produeix senyals; la gestió de casos els converteix en decisions defensables. Cada alerta a Didit té una font —activada per regla, activada per proveïdor o creada per analista— i un estat que reflecteix la seva posició en la investigació. Un analista obre l'alerta, revisa la transacció i les regles que es van activar, i decideix: descartar-la com a fals positiu, resoldre-la, escalar-la a un cas, retornar-la a l'usuari o moure-la cap a un SAR.

Els casos són el contenidor per a qualsevol cosa més gran que una única alerta. Diverses alertes sobre el mateix usuari —un pic de velocitat dilluns, un cop de contrapart sancionada dimecres— s'agrupen en un cas que conté la imatge completa, amb la seva pròpia prioritat i gravetat. El cas és el que investiga un investigador, i el cas és el que documenta la decisió de l'empresa.

Per què és important

Els reguladors no només esperen que detecteu activitat sospitosa, sinó que l'investigueu i la denuncieu, i que mostreu una pista d'auditoria neta de com vau arribar de l'alerta a la decisió. Una pila fragmentada va en contra vostre en tots els aspectes. Tornar a introduir dades entre un proveïdor de monitorització i una eina de casos introdueix errors. Un procés SAR basat en fulls de càlcul és impossible d'auditar i lent de defensar. I cada punt d'integració és un lloc on una alerta pot caure.

Col·lapsar la pila en un sol producte soluciona el problema operatiu i el regulador alhora. L'alerta, la investigació, l'analista que la va posseir i el SAR viuen tots en el mateix registre. La pista d'auditoria és contínua perquè res surt del sistema. I el cost s'escala amb les transaccions, no amb les llicències per usuari per a una eina de casos que també heu de mantenir.

Detalls tècnics

Quan s'activa una regla en una transacció, la resposta inclou l'estat i un alert_id:

{
  "transaction_id": "txn_3c81f0",
  "status": "IN_REVIEW",
  "risk_score": 64,
  "triggered_rules": [
    { "name": "Sanctioned counterparty", "bundle": "AML/CTF", "action": "CHANGE_STATUS" }
  ],
  "alert_id": "alrt_77a920"
}

La transacció en si es crea a través de l'API unificada /v3/, idempotent amb un transaction_id que controleu:

curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: $DIDIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "txn_3c81f0",
    "category": "finance",
    "amount": 24000,
    "currency": "EUR",
    "currency_kind": "fiat",
    "txn_date": "2026-05-21T14:50:00Z",
    "subject": { "vendor_data": "user_6610", "role": "SENDER", "entity_type": "INDIVIDUAL" },
    "counterparty": { "role": "RECEIVER", "entity_type": "INDIVIDUAL" }
  }'

Estats d'alerta. OPEN → INVESTIGATING → (AWAITING_USER) → PENDING_SAR → SAR_FILED, o finalitzar en RESOLVED o DISMISSED.

Estats de cas. OPEN, UNDER_REVIEW, AWAITING_USER, ON_HOLD, RESOLVED.

Webhooks. Subscriviu-vos a transaction.created i transaction.status.updated perquè els vostres sistemes es mantinguin sincronitzats a mesura que un analista mou una alerta a través del flux de treball.

Preu. 0,02 $ per transacció. La detecció AML realitzada en una part marcada durant una investigació es factura per separat a 0,20 $.

De l'alerta al SAR presentat

1. L'alerta s'obre. S'activa una regla, la transacció passa a IN_REVIEW i s'obre una alerta en estat OPEN amb les regles activadores adjuntes.
2. L'analista la recull. L'alerta passa a INVESTIGATING i s'assigna a un analista, que revisa l'historial de transaccions, el context de velocitat i qualsevol detecció AML.
3. Escalar o remediar. L'analista agrupa les alertes relacionades en un cas, o envia l'alerta a AWAITING_USER perquè el client pugui aclarir-la amb una prova de fons o una nova verificació.
4. Decidir sobre un SAR. Si l'activitat justifica la denúncia, l'alerta passa a PENDING_SAR, el SAR es prepara a la mateixa consola i, en el moment de la presentació, l'alerta passa a SAR_FILED.
5. Tancar. Les alertes que no justifiquen cap acció es resolen com a DISMISSED (fals positiu) o RESOLVED. Tot el rastre —qui va decidir què, quan— es manté en el registre.

Com que les alertes poden passar a AWAITING_USER, la investigació i el bucle d'autoremediació comparteixen la mateixa superfície: un analista pot retornar una alerta dubtosa a l'usuari en lloc de perdre-hi temps, i l'alerta es reprèn automàticament un cop l'usuari respon.

Casos d'ús

• Fintech — agrupar alertes de velocitat, estructuració i sancions en un sol compte en un cas abans de decidir sobre un SAR.
• Crypto — investigar alertes generades per l'exposició a la detecció de carteres juntament amb la velocitat en cadena en el mateix expedient de cas.
• Préstecs — gestionar alertes de patrons de frau (mula, identitat sintètica) fins a una decisió documentada sense una segona eina.
• Marketplaces — consolidar alertes d'abús de reemborsaments i contracàrrecs d'un venedor en un cas, i després presentar o descartar.
• iGaming — gestionar alertes de joc responsable i AML en un sol flux de treball, amb propietat de l'analista i una pista d'auditoria.

Com integrar-se amb Didit

1. Activeu els vostres paquets. A la Consola de Negoci, activeu els paquets de regles que s'adapten al vostre negoci perquè les alertes s'obrin contra les tipologies correctes.
2. Envieu transaccions. POST /v3/transactions/ a mesura que es mouen els diners, amb un transaction_id estable i vendor_data que vincula cada un al seu usuari o entitat.
3. Treballeu les alertes a la Consola. Investigueu, assigneu analistes, agrupeu alertes en casos i presenteu SARs, tot des de la mateixa superfície.
4. Sincronitzeu amb webhooks. Escolteu transaction.status.updated perquè els vostres propis sistemes reflecteixin els canvis d'estat d'alerta i de cas.

Com que tot es basa en l'API unificada /v3/, una sessió KYB pot generar les sessions KYC per als seus UBO, aquests usuaris passen a la monitorització de transaccions i una transacció marcada pot generar una KYC de remediació —una plataforma d'identitat i frau, de principi a fi.

Preguntes freqüents

Necessito una eina de gestió de casos separada?

No. Les alertes, els casos, l'assignació d'analistes, els estats d'investigació i la presentació de SAR estan integrats en el mateix producte i consola.

Per quins estats passa una alerta?

OPEN (oberta), INVESTIGATING (investigant), AWAITING_USER (esperant usuari), PENDING_SAR (SAR pendent), SAR_FILED (SAR presentat), RESOLVED (resolta) i DISMISSED (descartada). Els casos passen per OPEN (obert), UNDER_REVIEW (en revisió), AWAITING_USER (esperant usuari), ON_HOLD (en espera) i RESOLVED (resolt).

Puc assignar alertes a analistes específics?

Sí. Les alertes i els casos s'assignen a analistes, de manera que la propietat és clara i el rendiment és mesurable.

On es presenta el SAR?

A la mateixa consola on es va generar l'alerta. No hi ha exportació a una eina separada ni dades tornades a introduir, cosa que manté la pista d'auditoria contínua.

Quin és el cost?

0,02 $ per transacció, facturat per trucada sense mínims. La detecció AML realitzada en una part marcada durant una investigació es factura per separat a 0,20 $.

Preparat per començar?

Llegiu la visió general de la monitorització de transaccions a la documentació, vegeu com s'integra amb la resta de la plataforma a la pàgina del producte de monitorització de transaccions i consulteu els preus transparents per trucada a la pàgina de preus. Quan estigueu preparats, comenceu gratuïtament: 500 comprovacions KYC gratuïtes cada mes i monitorització de transaccions a 0,02 $ per trucada.