Browse documentation

Fidera documentation

Multi-party Checks

Screen people, companies, wallets, vessels, and aircraft with explicit roles in a single Applicant-owned Check.

Multi-party Checks model a business event without creating temporary customer records for every counterparty. The Check belongs to your Applicant; each subject records its own type, role, reference, and identifiers.

Subject types and roles

Supported types are person, company, wallet, vessel, and aircraft. Roles include customer, sender, receiver, intermediary, beneficial_owner, supplier, freight_forwarder, vessel, aircraft, and other.

Use reference_id on every subject when you need deterministic mapping back to a payment message, trade document, or internal party record.

Transaction example

{
  "type": "aml_screen",
  "use_case": "transaction",
  "mode": "sync",
  "reference_id": "payment-9842",
  "applicant_id": "7f9ee48f-4b03-4b51-93c8-629872f067cc",
  "datasets": ["sanctions", "export_controls", "crypto_wallets"],
  "subjects": [
    {
      "reference_id": "ordering-customer",
      "type": "person",
      "role": "sender",
      "name": "Jane Example",
      "date_of_birth": "1990-01-01",
      "identifiers": { "passport": "123456789" }
    },
    {
      "reference_id": "beneficiary",
      "type": "company",
      "role": "receiver",
      "name": "Example Trading Ltd",
      "country": "GB",
      "registration_number": "01234567"
    },
    {
      "reference_id": "settlement-address",
      "type": "wallet",
      "role": "receiver",
      "wallet_address": "0x1111111111111111111111111111111111111111"
    }
  ]
}

Matching inputs

Send the most authoritative structured identifiers available. Names alone produce less discriminating evidence than a name plus date of birth, nationality, registration number, IMO number, MMSI, or wallet address.

Put alternate known names in aliases. Put low-confidence transliterations, informal names, or noisy extraction variants in weak_aliases so policy can weight them separately.

Sync and async execution

Synchronous Checks are intended for bounded, latency-sensitive requests. Async mode is appropriate for large subject sets and background workflows. Persist the returned Check ID in both cases. Poll the Check or use webhooks to observe completion.