Shield
Verifex Shield
Fraud and AML transaction monitoring: every transaction you send gets a decision in milliseconds, with the rules that fired, a score, and a signed record of why.
What Shield does
- Decides each transaction against your rules: amount, velocity, new beneficiary, device and behaviour signals, MCC and currency risk, customer risk score.
- Screens the counterparty against sanctions and PEP lists in the same call, through Verifex screening.
- Counts the monthly AML scenarios (S1–S4) per sender and beneficiary and produces the monthly reports.
- Opens cases for review, keeps an append-only history, and sends webhooks.
- Lets a compliance team tune a rule, simulate the change over past decisions, and deploy it without engineering.
Two APIs, one engine
Both reach the same rules, cases and decisions. Use whichever fits the integration you have.
| API | Base path | Auth | When to use it |
|---|---|---|---|
| Native | /v1/risk | Bearer key | New integrations, the dashboard, scripts. Verifex's own shapes (JSON, snake_case lists). |
| SanctionScanner-compatible | /api | Basic: key id + key | Moving from SanctionScanner: the same paths, fields and response envelope, plus Shield extensions. |
Authentication
Use the secret API key from the dashboard. On the native API send it as a Bearer token; on the compatible API send Basic auth with the key's id as the user name and the same key as the password (the id must belong to that key). Send your own User-Agent (for example yourcompany-payments/1.0): requests identifying as Python's default Python-urllib are blocked at our network edge.
curl https://api.verifex.dev/v1/risk/decisions?outcome=block&limit=10 \
-H "Authorization: Bearer vfx_your_api_key"# Basic auth: your API key's id and the same secret key
curl https://api.verifex.dev/api/Transaction/Detail/TXN-1001 \
-u "key_id:vfx_your_api_key"Info
shield:admin to change rules, rulesets, thresholds, risk tables, webhooks or settings. A key without scopes (every key today, and the dashboard) has full access. Reading is never restricted by scope.Outcomes, scores and alarms
| Outcome | Meaning |
|---|---|
| clear | Let it through. |
| review | Let it through, and a person looks at it (a case is opened). |
| delay | Hold it briefly, then review. |
| escalate | Hold it for a senior reviewer. |
| block | Stop it. Always the answer for a blacklist hit, a strong sanctions match (score 95 or more) or a failed SIMA biometric check. A possible sanctions match escalates instead. |
- totalScore — the sum of the base scores of the rules that fired (SanctionScanner semantics). Its alarm (VeryLow … Critical) comes from your alarm thresholds.
- riskScore — Shield's own 0–100 score: the highest rule score plus 5 per extra rule. The outcome comes from it plus the hard overrides.
- A sanctions screen that times out or cannot certify a clear result never comes back as
clear: the outcome is held atreviewor above. - A transaction with no counterparty name is not sanctions-screened, and the answer says so (
COUNTERPARTY_NOT_SCREENED).
Evidence capsules
Every decision stores a capsule: the features it saw, the rule versions it used and the result, with a SHA-256 over its content and a server signature. The database refuses any change to a stored capsule. Replay a decision to check it reproduces with the rule versions it recorded (GET /v1/risk/decisions/{id}/replay).