Transaction Screening

Fordefi can screen outgoing transactions with external screening providers — Blockaid and Hypernative — before they are signed, and return the results through the API alongside Fordefi's own risk engine output. Screening is opt-in per organization: an admin activates a provider by saving valid credentials for it in Settings > Screening in the web console. See Integrate transaction screening providers for the setup and the supported chains.

Once a provider is active, its findings reach you in two forms:

• Risk objects, in the existing risks array, so screening findings arrive through the same field your integration already reads.
• Screening objects, in a screening array, which report the per-provider outcome — including a clean result — and carry the provider's own response details.

Screening findings are turned into risk objects, one per finding:

• Blockaid: One risk per entry in validation.features whose type is not Benign.
• Hypernative: One risk per entry in findings whose severity is neither accept nor autoAccept.

Every endpoint that returns risks also returns a screening array, with one entry per external provider that the transaction was screened with. Fordefi's own risk engine is not represented in screening. The array may be empty — for example when no provider is active for the organization.

Read screening rather than inferring the outcome from risks: a provider that returned a clean result and a provider that was never called both produce zero risks, and only screening tells them apart.

screening_details carries through the provider's own response, so you can correlate a Fordefi transaction with a screening on the provider's platform.

A Blockaid screening object:

"screening": [
  {
    "vendor": "blockaid",
    "result": "Malicious",
    "title": "known_malicious",
    "description": "A known malicious address is involved in the transaction",
    "screening_details": {
      "validation": {
        "status": "Success",
        "result_type": "Malicious",
        "description": "A known malicious address is involved in the transaction",
        "reason": "b",
        "classification": "known_malicious",
        "features": [
          {
            "type": "Malicious",
            "feature_id": "KNOWN_MALICIOUS_ADDRESS",
            "description": "This address has recorded malicious activity",
            "address": "0x0a5738064da9dda3cf4a4ae8d8e49b16fd7467c5"
          }
        ]
      }
    }
  }
]

A Hypernative screening object:

"screening": [
  {
    "vendor": "hypernative",
    "result": "deny",
    "title": "Phishing victim - approval",
    "description": "[Simulated] An address approved funds to a phishing/scamming address",
    "screening_details": {
      "data": {
        "recommendation": "deny",
        "assessmentId": "fdbf8e7b-8387-4fbf-b3fc-3eeb9ca39d54",
        "assessmentTimestamp": "2026-01-21T08:01:18.375Z",
        "findings": [
          {
            "typeId": "S-1925",
            "title": "Phishing victim - approval",
            "description": "[Simulated] An address approved funds to a phishing/scamming address",
            "severity": "Deny"
          }
        ]
      },
      "error": null
    }
  }
]

XD

How the policy engine treats an unusable screening result depends on why it is unusable:

• Unsupported chain: A Risk condition does not match, and policy evaluation continues to the next rule. This covers both a chain type that Fordefi does not screen and a provider that returns an unsupported-chain error, for example on an unsupported EVM chain.
• Timeout, malformed response, or other provider error: The result is indeterminate, and Fordefi falls back to the default policy rule, the same fallback used when simulation data is missing.

Because an unavailable provider falls back to the default rule, we recommend setting a strict default policy rule.

Learn more:

• Integrate transaction screening providers
• Set policy rules on screening results
• Simulate transactions