Velocity, Structuring, sanktionierte Gegenpartei, Hochrisikogebiet. Case-Queue,
SAR-fähiger Workflow, Travel Rule. Automatische Pause und erneute Verifizierung des Nutzers, wenn
eine Soft Rule ausgelöst wird.
So funktioniert's
Vom Sign-up zum verifizierten Nutzer in vier Schritten.
Schritt 01
Workflow erstellen
Wähle die gewünschten Prüfungen aus, ID, Liveness, Face Match, Sanktionen, Adresse, Alter, Telefon, E-Mail, benutzerdefinierte Fragen. Ziehe sie im Dashboard in einen Flow oder poste denselben Flow an unsere API. Verzweige nach Bedingungen, führe A/B-Tests durch, kein Code erforderlich.
Schritt 02
Integrieren
Bette nativ mit unserem Web-, iOS-, Android-, React Native- oder Flutter-SDK ein. Leite auf eine gehostete Seite weiter. Oder sende deinem Nutzer einfach einen Link, per E-Mail, SMS, WhatsApp, überall. Wähle, was zu deinem Stack passt.
Schritt 03
Nutzer durchläuft den Flow
Didit hostet die Kamera, die Beleuchtungshinweise, die mobile Übergabe und die Barrierefreiheit. Während der Nutzer den Flow durchläuft, bewerten wir über 200 Betrugssignale in Echtzeit und verifizieren jedes Feld anhand autoritativer Datenquellen. Ergebnis in unter zwei Sekunden.
Schritt 04
Du erhältst die Ergebnisse
Echtzeit-signierte Webhooks halten deine Datenbank synchron, sobald ein Nutzer genehmigt, abgelehnt oder zur Überprüfung gesendet wird. Frage die API bei Bedarf ab. Oder öffne die Konsole, um jede Session, jedes Signal zu prüfen und Fälle nach deinen Vorstellungen zu verwalten.
Für Compliance entwickelt · Für Entwickler gemacht · Offen im Design
Sechs Funktionen. Eine Produktlinie. Transaction Monitoring.
Jede Funktion ist Teil desselben Moduls, ein Endpunkt, eine JSON-Struktur, ein Preis. Aktiviere Bundles pro Anwendung, passe Schwellenwerte an, ohne die Voreinstellung zu verlieren, oder erstelle benutzerdefinierte Regeln mit denselben Operatoren.
Entscheidungen in unter einer Sekunde für jede Transaktion.
Sende eine Transaktion, erhalte das Ergebnis in der Antwort, typischerweise 150–350 ms für eine Fiat-Überweisung gegen zwölf aktive Regeln. Vier Status (genehmigt, in Überprüfung, abgelehnt, wartet auf Nutzer) plus die kumulative Punktzahl und die Regeln, die zutrafen. Kein Polling.
EntscheidungPOST /v3/transactions/ · 238 ms
txn_finance0001EUR 1.200 · AUSGEHEND
Regeln · 12 aktivScore 42
APPROVED
IN_REVIEW
DECLINED
AWAITING_USER
02 · 11 vorgefertigte Bundles
Über 150 vordefinierte Regeln. Am ersten Tag produktionsreif.
Elf Bundles werden automatisch für jede Anwendung erstellt, Finanzen, AML + CTF (Terrorismusfinanzierungsbekämpfung), FATF (Financial Action Task Force), Krypto-Monitoring, Travel Rule, Device Intelligence, Betrugsprävention, Anomalieerkennung, verantwortungsvolles Spielen, E-Commerce, BNPL (Buy-Now-Pay-Later). Passe Schwellenwerte an oder deaktiviere sie, Voreinstellungen bleiben für die regulatorische Baseline erhalten.
Aggregationen, die Einzeltransaktionsprüfungen entgehen.
Velocity-Regeln aggregieren die Historie über Zeitfenster von einer Stunde bis 30 Tagen. Drei Metriken, Anzahl, Summe oder eindeutige Anzahl, pro Subjekt, Gegenpartei, Gerät oder Richtung. Vorindiziert, sodass die Fenstergröße die Latenz nicht erhöht.
Velocity-RegelFenster: 7d
count
eingehend >= 20
sum
ausgehend >= $50.000
distinct
Gegenparteien >= 6
pro Subjekt · pro Gerät · pro Gegenpartei ausgewertet
04 · Fälle + SAR
Jeder Alarm landet in einer Warteschlange. SAR-ready.
Jede in Überprüfung befindliche oder abgelehnte Transaktion generiert eine Warnung im Case Management mit übereinstimmenden Regeln, Beitragsbewertung und verknüpften Transaktionen. Analysten triagieren über einen Zustandsautomaten und erstellen dann ein abgabebereites SAR (Suspicious Activity Report) PDF plus strukturierte Metadaten für deine Financial Intelligence Unit.
Alarm · Fall_8f3zugewiesen: m.lopez
OPENRegel: schnelles Ein- und Auszahlen
INVESTIGATINGNachweis angehängt · 3 Transaktionen
PENDING_SARPrüfer: m.lopez
SAR_FILEDFinCEN-Referenz ausstehend
SAR generieren → sar_8f3.pdf + structured_metadata.json
05 · Automatische Behebung
Der „Happy Path“ erfordert keine Analystenzeit.
Wenn eine Soft Rule ausgelöst wird, zum Beispiel schnelle Ein- und Auszahlungen auf einem ansonsten unauffälligen Konto, halten wir die Transaktion zurück und senden dem Nutzer einen One-Tap-Re-Verifizierungslink per E-Mail. Wenn er besteht, wird die Transaktion genehmigt; wenn er scheitert oder abbricht, wird sie abgelehnt. Kein Analyst muss den Fall öffnen.
Automatische BehebungAnalystenzeit: 0s
Regelverstöße
schnelles Ein- und Auszahlen · +60 Punkte · AWAITING_USER
KYC-Nachbesserung gesendet
One-Tap-Link · Selfie + Liveness · Handy des Nutzers
Nutzer besteht
Transaktion wird automatisch gelöst → GENEHMIGT
06 · Fiat + Krypto
Eine Engine für beide Hälften der Überweisung.
Markiere eine Überweisung am selben Endpoint als Fiat oder Krypto. Krypto-Transfers durchlaufen automatisch ein On-Chain-Wallet-Screening für 0,15 $ pro Prüfung (oder du bringst deinen eigenen Screening-Anbieter mit), die Antwort wird mit einem Risikoscore, einer Aufschlüsselung der Geldquellen und einem Netzwerkdiagramm angereichert. 12 regionale Travel-Rule-Regime sind sofort einsatzbereit.
Eine EngineFiat + Krypto
Fiat · EUR
Geschwindigkeit 7d
Strukturierungs-Erkennung
PEP · Sanktionen
Geräte-Fingerabdruck
Krypto · BTC
Geschwindigkeit 7d
Mixer / Darknet-Exposition
On-Chain-Wallet-Risiko
Travel Rule · FATF R.16
Integrieren
Ein Endpunkt zum Erfassen. Ein Webhook zum Reagieren.
Sende Transaktionen an den Ingest-Endpunkt für Echtzeit-Screening und abonniere Events am Webhook, damit deine App reagiert, wenn ein Analyst einen Fall löst oder die automatische Behebung abgeschlossen ist. Die Regeln selbst werden standardmäßig in der Business Console angepasst.
Verifiziere den X-Signature-V2-Header, bevor du einer Payload vertraust.Dokumentation →
Agenten-fertige Integration
Implementiere Transaction Monitoring mit einem Prompt.
Füge den folgenden Block in Claude Code, Cursor, Codex, Devin, Aider oder Replit Agent ein. Ergänze deinen Stack. Der Agent provisioniert Didit, verbindet den Transaktions-Ingest-Endpoint, abonniert die Resolution-Webhooks und liefert aus.
didit-integration-prompt.md
# Didit Transaction Monitoring — integrate in 5 minutes
You are integrating Didit's Transaction Monitoring into the my_stack codebase.
Follow these steps exactly. Every URL, header, and enum value below is
canonical — do not paraphrase or "improve" them.
## 1. Provision an account
- Sign up: https://business.didit.me (no credit card required).
- Enable Transaction Monitoring on an application from
Console -> Applications -> [app] -> Transactions.
- The moment you enable it, the 150+ preset rule library is auto-created on
the application. You can tune thresholds in the console — there is no
public rule-CRUD API by design (compliance teams own rule config).
## 2. Submit transactions
Every transaction is screened in real time. One POST, one verdict.
POST https://verification.didit.me/v3/transactions/
Headers:
x-api-key: YOUR_API_KEY
Content-Type: application/json
Body (minimum viable shape — see docs for full schema):
{
"txn_id": "finance0001",
"transaction_category": "finance",
"transaction_details": {
"direction": "OUTBOUND",
"amount": "1200.00",
"currency": "EUR",
"currency_kind": "fiat"
},
"subject": {
"role": "applicant",
"entity_type": "individual",
"vendor_data": "user-123"
},
"counterparty": {
"role": "counterparty",
"entity_type": "individual",
"full_name": "Jane Doe",
"country_code": "DE"
}
}
Response (synchronous): JSON with the computed risk score, the matched
rules, and the verdict status (see step 3).
## 3. Read the verdict
Every transaction lands on one of four statuses (UPPERCASE, strict enum):
- APPROVED — below all thresholds
- IN_REVIEW — score >= review threshold (default 60) OR a rule
set change_status to IN_REVIEW
- DECLINED — score >= decline threshold (default 85) OR a rule
set change_status to DECLINED, OR an entity matched
a blocklist (blocklist always wins, evaluated first)
- AWAITING_USER — a rule fired with change_status AWAITING_USER; Didit
created a remediation Know Your Customer (KYC) session automatically and
the verification_url is included in the response
The response also includes:
- score (number) — cumulative risk score
- rule_runs[] — every rule evaluated, with match/no-match
- screening_results — Anti-Money Laundering (AML), wallet, and IP enrichment outcomes
- decision_reason — short string when DECLINED
- remediation_session_url — only when status is AWAITING_USER
## 4. Crypto + Travel Rule
For crypto transfers, set currency_kind to "crypto" and put the wallet
addresses in payment_method.account_id. Didit screens on-chain wallet
risk automatically — no extra API call.
For VASP transfers requiring FATF R.16 (Travel Rule), set
transaction_category to "travel_rule" and include travel_rule_details
with status, protocol (TRISA / TRP / OpenVASP), originator_data, and
beneficiary_data. 12 regional regimes ship with their own rule sets
(EU, UK, Singapore, Hong Kong, Japan, etc.).
## 5. Webhooks
Register one webhook destination once (you can reuse the same destination
for KYC, AML, and Transaction Monitoring events):
POST https://verification.didit.me/v3/webhook/destinations/
Body: url, subscribed_events: [
"transaction.created",
"transaction.updated",
"transaction.status.changed",
"transaction.alert.generated"
]
Every webhook delivery carries an X-Signature-V2 header you MUST verify
before trusting the payload. HMAC-SHA256 verification MUST run against the raw body bytes (the raw payload as Didit sent it) BEFORE any JSON parsing — re-serialising the parsed body changes whitespace and key order, which invalidates the signature.Algorithm:
1. sortKeys(payload) recursively
2. shortenFloats (truncate trailing zeros after the decimal point)
3. JSON.stringify the result
4. HMAC-SHA256 with secret_shared_key
5. Hex-encode, compare to X-Signature-V2.
## 6. Hard rules — do not change
- Base URL for /v3/* endpoints is verification.didit.me (NOT apx.didit.me).
- Auth header is x-api-key (lowercase, hyphenated).
- Status enums are UPPERCASE: APPROVED, IN_REVIEW, DECLINED, AWAITING_USER.
- Webhook signature header is X-Signature-V2 (NOT X-Signature).
- Always verify webhook signatures before trusting payload data.
- Do NOT create rules via API — rules are configured in the Business
Console only. This is a design choice: compliance teams own rule config.
## 7. Pricing reference (public)
- Transaction Monitoring: $0.02 per transaction monitored.
- AML screening fired by a Transaction Monitoring rule: billed at
$0.20 per AML check (separate line item).
- Wallet Screening (KYT) fired by a crypto rule: $0.15 per screening —
or bring your own screening provider and run it inside Didit.
- 500 free verifications every month, forever, on every account.
- No minimums, no contracts, no overage surprises.
## 8. Verify your integration
- Send a sandbox transaction with amount 9500 EUR — this trips the
single-transaction-just-below-threshold preset (+25 score) so you can
confirm the response carries rule_runs and a non-zero score.
- Trip a structuring pattern by submitting 20 sandbox transfers under
10,000 EUR for the same vendor_data within 30 days — the
structuring-outbound preset returns IN_REVIEW.
- Check the Business Console -> Transactions -> Cases tab to confirm an
alert was generated for every IN_REVIEW.
When in doubt: https://docs.didit.me/transaction-monitoring/overview
Brauchst du mehr Kontext? Siehe die vollständige Moduldokumentation.docs.didit.me →
Compliant by Design
Ein neues Land mit einem Klick erschließen. Wir machen die Arbeit.
Wir gründen lokale Tochtergesellschaften, sichern Lizenzen, führen Penetrationstests durch, erhalten Zertifizierungen und passen uns jeder neuen Regulierung an. Um Verifizierungen in einem neuen Land zu starten, legst du einfach einen Schalter um. Über 220 Länder live, vierteljährlich auditiert und Pen-getestet, der einzige Identitätsanbieter, den eine EU-Mitgliedsregierung offiziell als sicherer als die persönliche Verifizierung eingestuft hat.
Vordefinierte Regeln werden bei jeder Anwendung automatisch erstellt.
0
Vorgefertigte Bundles für Finanzen, AML, Krypto, FATF, Betrug, Gaming.
<0ms
Mediane End-to-End-Entscheidungslatenz pro Transaktion.
$0.00
Pro Transaktion. 500 kostenlos jeden Monat, für immer.
Drei Stufen, eine Preisliste
Kostenlos starten. Nach Nutzung zahlen. Bis zum Enterprise-Level skalieren.
500 kostenlose Verifizierungen jeden Monat, für immer. Pay-as-you-go für die Produktion. Individuelle Verträge, Datenresidenz und SLAs (Service Level Agreements) für Enterprise.
Kostenlos starten → nur zahlen, wenn eine Prüfung läuft → Enterprise für einen individuellen Vertrag, SLA oder Datenresidenz freischalten.
FAQ
Häufige Fragen
What is Didit?
Didit is infrastructure for identity and fraud, the platform we wished existed when we were building products ourselves: open, flexible, and developer-friendly, so it works as a real part of your stack instead of a black box you integrate around.
One API covers verifying people (KYC, know your customer), verifying businesses (KYB, know your business), screening crypto wallets (KYT, know your transaction), and monitoring transactions in real time, on a stack built to be:
Fast, sub-2-second p99 on every session
Reliable, in production with 1,500+ companies across 220+ countries
Secure, SOC 2 Type 1, ISO 27001, GDPR-native, and formally attested by Spain's financial regulator as safer than verifying someone in person
The footprint underneath: 14,000+ document types in 48+ languages, 1,000+ data sources, and 200+ fraud signals on every session. The Didit infrastructure dynamically learns from every session and gets better every day.
What's in the rule bundles I get out of the box?
11 seeded bundles, 150+ presets. Every application with Transaction Monitoring enabled gets the full library auto-created on day one. The 11 bundles: finance (structuring, large transactions, layering, mule fan-in), aml_ctf (sanctions counterparty, Politically-Exposed-Person (PEP) exposure, suspicious payment references), aml_monitoring (blockchain-derived high-risk source-of-funds), anomaly_detection (high velocity, dormant reactivation), fatf (high-risk jurisdiction exposure), device_intelligence (multi-accounting via shared fingerprints, Virtual Private Network (VPN) / proxy, impossible travel), fraud_prevention (account takeover, Authorised Push Payment fraud, consortium-flagged counterparties), crypto_monitoring (mixer / darknet / sanctioned wallet exposure, chain hopping, unhosted wallets), travel_rule (12 regional Financial Action Task Force (FATF) Recommendation 16 regimes), responsible_gaming (rapid deposits, self-exclusion, off-hours play), and e_commerce (card testing, chargeback indicators, billing-country mismatch). Tune any threshold, switch a rule to test mode, or disable it, but presets cannot be deleted, so the regulator baseline always stays intact.
How fast is real time, in milliseconds?
Sub-second on the median. A POST /v3/transactions/ returns the verdict synchronously, typical end-to-end latency is 150-350 ms for a fiat transaction running against 12 active rules. Crypto transactions add ~200 ms when wallet screening fires (on-chain risk lookup). Velocity aggregations over 7d / 30d windows are pre-indexed, so window size does not blow up latency. You never have to poll, the verdict is in the response body.
How fast is the verification for my end user?
The full flow normally takes under 30 seconds end-to-end, pick up the ID, snap the document, snap the selfie, done. That is the fastest in the market. Legacy KYC providers usually take more than 90 seconds for the same flow.
On the back end, Didit returns the result in under two seconds at p99, measured from the moment the user finishes the selfie to the moment your webhook fires. Mobile capture is tuned for slow phones and slow networks: progressive image compression, lazy software development kit load, and a one-tap hand-off from desktop to phone via QR code if the user starts on web.
How does it work with Case Management?
Every `IN_REVIEW` or `DECLINED` transaction generates an alert that lands in the Case Management queue automatically. Alerts inherit the source (RULE for a preset match, PROVIDER for a wallet or AML hit), the matched rule library_key, the score contribution, and the linked transactions. Analysts triage from /console/cases, link related alerts into a single case, and resolve through the OPEN / UNDER_REVIEW / AWAITING_USER / ON_HOLD / RESOLVED lifecycle. Case Management is free with every Business Console workspace, see /products/case-management for the full surface.
What happens if a user fails, abandons, or expires?
Every session lands on one of seven clear statuses, so your code always knows what to do:
Approved, every check passed. Move the user forward.
Declined, one or more checks failed. You can allow the user to resubmit the specific failed step (for example, re-take the selfie) without re-running the whole flow.
In Review, flagged for compliance review. Open the case in the console, see every signal, decide approve or decline.
In Progress, user is mid-flow.
Not Started, link sent, user has not opened it yet. Send a reminder if it sits too long.
Abandoned, user opened the link but did not finish in time. Re-engage or expire.
Expired, the session link aged out. Create a new session.
A signed webhook fires on every status change, so your database always stays in sync. Abandoned and declined sessions are free.
Where does my customer data live and how is it protected?
Production data is processed and stored in the European Union by default, on Amazon Web Services. Enterprise contracts can request alternative regions for jurisdictions whose regulators require it.
Encryption everywhere. AES-256 at rest across every database, object store, and backup. Transport Layer Security 1.3 in transit on every API call, webhook, and Business Console session. Biometric data is encrypted under a separate Customer Master Key.
Retention is yours to control. Default retention is indefinite (unlimited) unless you configure shorter, between 30 days and 10 years per application, and you can delete any individual session at any time from the dashboard or the API.
Certifications: SOC 2 Type 1 (Type 2 audit in progress), ISO/IEC 27001:2022, iBeta Level 1 PAD, and a public attestation from Spain''s Tesoro / SEPBLAC / CNMV that Didit''s remote identity verification is safer than verifying someone in person. Full report at /security-compliance.
Is Didit compliant for my industry?
Didit ships compliant by default for the regulators that matter to identity infrastructure:
GDPR + UK GDPR, controller / processor split, full Data Processing Agreement published, lead supervisory authority named (Spain''s AEPD).
AMLD6 + EU AML Single Rulebook, 1,300+ sanctions, politically exposed person, and adverse-media lists screened in real time.
eIDAS 2.0, EU Digital Identity Wallet aligned; reusable-identity ready.
MiCA (Markets in Crypto-Assets), ready for crypto on-ramps, exchanges, and custodians.
DORA, Digital Operational Resilience Act, EU financial-services operational resilience.
BIPA, CUBI, Washington HB 1493, CCPA / CPRA, US biometric privacy (Illinois, Texas, Washington) and California consumer privacy.
UK Online Safety Act, age-gating and child-safety obligations.
FATF Travel Rule, originator and beneficiary data on crypto transfers, IVMS-101 interoperable.