Fraud confirmation

Yes, if after a later review it is confirmed that a specific transaction corresponded to a fraud attempt, the consumer can report it to DAF. This information is used internally to reinforce future detections on the same document or identity. This step is optional.

Endpoint

POST /v2/daf/fraud-report

Headers

Name	Type	Required	Description
Authorization	string	Yes	consumer Token in format Bearer <token> (see Authentication).
consumer-id	string	Yes	Consumer identifier.

Request body

Content-Type: application/json

Parameters

Parameter	Type	Required	Description
transactionId	string	Yes	Identifier of the DAF transaction that is confirmed as fraud.
categories	array	Yes	One or more categories of the detected fraud. Each value must belong to the catalog of valid categories (see below).
comment	string	No	Free-form comment, max. 500 characters.

Valid categories

The field categories only accepts the following codes:

Code	Description
document_is_manipulated	The document is manipulated.
document_shown_from_screen	The document is shown from a screen.
document_is_printed_copy	The document is a printed copy.
selfie_shown_from_screen	The selfie is shown from a screen.
selfie_is_manipulated	The selfie is manipulated.
selfie_document_portrait_mismatch	The selfie does not match the portrait in the document.
injected_media	The content (image/video) was injected.

This list reflects the current catalog at the time this guide was published. The service validates the categories against the updated catalog; send only the codes from this table.

Request example

{
  "transactionId": "1c7d...e9",
  "categories": ["document_is_manipulated", "selfie_is_manipulated"],
  "comment": "Confirmed as fraud after internal review"
}

Responses

200 Success

{
  "accepted": true
}

All applicable actions of the confirmation were recorded correctly. This includes enrolling the face in the applicable blocklists (see below). The operation is idempotent: if the face was already in a blocklist, or if the transaction had already been reported previously, the retry is also considered a success and returns 200.

400 Bad Request

One of the categories sent does not belong to the catalog of valid categories. No action is recorded; correct the categories and retry.

422 Unprocessable Entity

The transaction does not allow reporting: only completed transactions in status COMPLETED.

503 Service Unavailable

One of the applicable actions of the confirmation could not be completed. The confirmation is not considered fully recorded; the consumer must retry later or, if the problem persists, report it to support indicating the transactionId. The operation is idempotent, so retrying is safe.

Face blocklists

When the transaction confirmed as fraud includes a selfie, its face is enrolled in the applicable blocklists, so that future validations detect it (codes 200/201, see result response):

• Platform blocklist: the face is always enrolled in the platform's own blocklist.

• Global blocklist: additionally, if the platform participates in the shared global blocklist, the face is also enrolled in it.

Participation in the global blocklist is configurable per platform (enabled by default) and is coordinated with Facephi; it is not controlled through the API. The setting is symmetrical: it affects both the search during validation (a platform without a global blocklist is only compared against its own blocklist) as well as the enrollment in this fraud confirmation (the face is added only to the platform blocklist). If the transaction was processed without a selfie (without TOKEN_FACE_IMAGE), no face is enrolled in any blocklist.

It is recommended to send a single fraud report per transaction. However, retrying is safe: the operation is idempotent and an already registered report returns 200 without duplicating effects.