在 2027 年 7 月 10 日前，
满足 AMLR 客户检查要求。

# Integrate Didit for AMLR customer due diligence

Integrate Didit into <my_stack> to run the customer checks that the EU
Anti-Money Laundering Regulation (AMLR, Regulation (EU) 2024/1624) will
require from 10 July 2027. Didit supplies the checks and the evidence. The
obliged entity keeps every decision and stays fully liable (Article 18).
This prompt is not legal advice.

## What stays with the obliged entity (never automate these away)
Article 18(3) lists six tasks that cannot be outsourced:
- proposing and approving the business-wide risk assessment
- approving internal policies, procedures and controls
- deciding the risk profile of a customer
- deciding to enter a business relationship or carry out a transaction
- reporting to the financial intelligence unit (FIU)
- approving the criteria for detecting suspicious transactions
Build the integration so that a named person takes each of these decisions.
Article 76(5) also requires meaningful human intervention on automated
decisions to accept or refuse a customer.

## Published prices used below
- Full KYC (know your customer) check: $0.33
- AML (anti-money laundering) screening: $0.20 per check
- Ongoing AML monitoring: $0.07 per person per year
For every other module, read https://didit.me/pricing. Do not invent a price.

## 1. Create the applications and the workflow
Create an account at https://business.didit.me. Live and sandbox are separate
applications. Sandbox outcomes are simulated. Store the application keys and
workflow UUIDs in server-side configuration. Never expose a key to a browser.

Build the workflow in the Console, or with
POST https://verification.didit.me/v3/workflows/.
Map the checks to the regulation:
- Identification and verification (Article 22): either a digital ID wallet
  (the electronic identification route of Article 22(6)(b)) or ID
  Verification with chip reading, liveness and face match (the document
  route of Article 22(6)(a)). Which route a customer takes is the obliged
  entity's policy. Record the route and the reason in your own system.
- Sanctions and PEP (politically exposed person) screening (Article 20):
  add AML Screening.
- Purpose and source of funds (Article 25): add a Questionnaire.
- Companies and beneficial owners (Articles 51 to 62): use a KYB (know your
  business) workflow and start a linked identity session for each owner.
  The AMLR ownership test is 25% or more, with control assessed in parallel.
  Registry tiers vary by country, and a register alone is not sufficient
  verification.
Publish the draft. Existing sessions keep the workflow version they started
with.

## 2. Create a session for each customer

  curl -X POST https://verification.didit.me/v3/session/ \
    -H "x-api-key: <application-key>" \
    -H "Content-Type: application/json" \
    -d '{
      "workflow_id": "<workflow-uuid>",
      "vendor_data": "<your-customer-id>"
    }'

The response contains "url". Redirect the customer to it, or embed the hosted
flow. vendor_data is your own stable reference and is returned on session
events. Within one application only one unfinished session can exist per
(workflow_id, vendor_data) pair.

## 3. Receive authenticated results
Register a webhook destination for status.updated and data.updated and store
its secret_shared_key on the server.
Verify before reading a result or changing a customer's data:
- X-Signature-V2: HMAC-SHA256 over recursively sorted, compact JSON with
  Unicode preserved. This header does not sign raw bytes.
- X-Signature: HMAC-SHA256 over the exact raw request bytes, captured before
  any JSON middleware.
- Check the signature format and length before a constant-time comparison.
- Validate X-Timestamp and reject a difference greater than 300 seconds.
  Require it to match the timestamp in the authenticated payload. The header
  is not signed, so a header checked alone can be replaced on a replay.
- Make processing idempotent before any side effect: a retry reuses the same
  event_id, so key on event_id and skip an event you have already stored.
  Durably queue the work before acknowledging.

Session statuses: Approved, Declined, In Review, In Progress, Not Started,
Abandoned, Expired, Kyc Expired, Resubmitted, Awaiting User.
- "Approved" and "Declined" are verification results, not onboarding
  decisions. Store the result, then let the obliged entity's own process
  decide.
- "In Review" goes to a human reviewer.
For reconciliation read
GET https://verification.didit.me/v3/session/{sessionId}/decision/.

## 4. Keep watching (Article 26)
Enable ongoing AML monitoring for approved customers. Didit re-screens daily
and re-screens fire the usual status.updated and data.updated events.
Store a risk class and a next review date for each customer in your own
system. Article 26(2) caps the interval between updates of customer
information at 1 year for higher-risk customers and 5 years for all others,
with event triggers on top. When a review is due, create a new session.

## 5. Keep the record (Article 77)
Records are kept for 5 years from the end of the business relationship, the
occasional transaction or the refusal, and personal data is then deleted
unless another law or an authority requires otherwise.
- Set retention in Business Console -> App Settings -> Data (1 month to 10
  years). The clock that matters starts when the relationship ends, so either
  size the window for that or export the evidence into the obliged entity's
  own archive.
- Delete a session on demand with
  DELETE https://verification.didit.me/v3/session/{session_id}/delete/.
Store the session id, the status, the workflow version, the route used and
the name of the person who took the onboarding decision.

## 6. Verify the integration
1. In the sandbox application, run one customer through the wallet route and
   one through the document route. Confirm both write the same record shape.
2. Send a webhook with a wrong signature and confirm it is rejected with 401.
3. Confirm an "In Review" result reaches a reviewer and that no code path
   onboards a customer without a recorded human decision.
4. Confirm sandbox and live traffic use separate applications.

Docs: https://docs.didit.me/getting-started/amlr-compliance