KYB Packages

Enigma offers two packages for business verification and KYB compliance. Each package is composed of attributes, the foundational business identity information for the best matching businesses, and tasks, which evaluate how those attributes compare to the information provided.

The right KYB package depends on what you're trying to accomplish:

Choose identify if you need basic identity matching and data enrichment workflows such as data enrichment, onboarding pre-fill, and third party verification.
Choose verify if you need compliance validation and registration status for workflows such as payment processing, lending, and business banking.

Specify your package with the package query parameter. It defaults to verify when omitted; if you're not sure which to use, start with verify.

Both packages can be extended with add-on tasks—such as watchlist screening and TIN/SSN verification—requested through the attrs parameter.

If you only need a few specific attributes for the matched business — not a full package or any verification tasks — use the products parameter instead of package.

Attribute and Task Comparison

	Identify	Verify
Registered (legal) entity attributes
Entity name(s)	✓	✓
Entity type	✓	✓
Formation date	✓	✓
Registration attributes
Registration state	✓	✓
Date issued	✓	✓
File number	✓	✓
Registered name	✓	✓
Registered person name and title(s)	✓	✓
Registered addresses	✓	✓
Jurisdiction type	✗	✓
Home jurisdiction state	✗	✓
Registration status, sub status, and status detail	✗	✓
Brand attributes
Brand name(s)	✓	✓
High risk activities	✓	✓
Industry classification	✓	✓
Website(s)	✓	✓
Operating location names and addresses	✓	✓
Tasks
Name verification (SoS-specific or any source)	✓	✓
Address verification (SoS-specific or any source)	✓	✓
Person verification	✗	✓
Domestic registration verification	✗	✓

Add-On Tasks

All add-on tasks work with both the Identify and Verify packages. Choose the add-ons tasks that match your verification requirements.

Request add-ons via the attrs query parameter, for example ?attrs=watchlist,tin_verification. Add-ons must be enabled for your account — contact us to discuss access.

Task	`attrs` value	Description
TIN (EIN) Verification	`tin_verification`	Checks that the submitted EIN is valid and that it matches the business name submitted. Requires `top_n=1`.
Watchlist Screening	`watchlist`	Screens the submitted business names against sanctions, debarment, and PEP watchlists — OFAC SDN and non-SDN, the UN Consolidated List, the World Bank debarment list, and PEP officials.
SSN Verification	`ssn_verification`	Checks that the SSN is valid and that it matches the submitted person's last name against IRS records. Requires `top_n=1`.
Negative News	`negative_news`	Returns recent negative news articles for matched legal entities, delivered through a `background_task` object

See add-on tasks for more information.

Add-on attributes

You can also request attributes that are not included in either package. See add-on attributes for more information.

Attribute-only requests (`products`)

When you only need a few specific attributes for the best-matching business — and not the full attribute set of a package or any verification tasks — request them with the products query parameter instead of package. products and package are mutually exclusive; supplying both returns HTTP 400. products is likewise mutually exclusive with attrs — list the attributes you want directly in products.

A products request:

Matches the business from the submitted name, address, and other identifiers, exactly as a packaged request does.
Returns only the matched entity ids (the id on each registered_entity, and id plus registered_entity_ids on each brand) plus the attributes you named in products. No package attribute bundle is included.
Runs no verification suite. By default the response carries an empty risk_summary. A few attributes still add a task — watchlist (watchlist screen), tin_verification, and ssn_verification — so the risk_summary is not necessarily empty. Those task-adding attributes require top_n=1.

products accepts the same attribute names as attrs — see the full list of available attributes — including the dotted registration.<attribute> form for individual registration fields (for example registration.status, registration.file_number). Attributes that add a task work here too: watchlist, tin_verification, and ssn_verification are all available on products, and require top_n=1. products must list at least one attribute, and every value must be a recognized attribute — an unknown value returns HTTP 400 (unlike attrs, which silently ignores unrecognized values).

# Just the latest card transaction count for the matched brand — no package, no tasks
curl -X POST "https://api.enigma.com/v2/kyb/?products=card_transactions_count" \
  -H "x-api-key: $ENIGMA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "name": "Acme Corp", "address": { "city": "New York", "state": "NY" } }'

The same add-on attributes and tasks available to the packages can be requested via products. Add-ons must be enabled for your account — contact us to discuss access.

Watchlist Screening

Watchlist screening checks a business — or a single individual — against government sanctions, debarment, and politically exposed person (PEP) lists, so you can catch entities you may be prohibited from doing business with. Enigma screens each submitted name against five lists: the OFAC SDN and non-SDN lists, the UN Consolidated List, the World Bank debarment list, and PEP officials.

Screening is an add-on, requested with attrs=watchlist, and it works two ways:

Alongside a business — add watchlist to a normal verify or identify request. Enigma matches the business as usual and screens the matched legal entity and the people registered on it.
On a person by itself — submit only a person, with no business input, to screen an individual such as a beneficial owner, officer, or applicant when there is no business to match.

However you screen, the result comes back in two places:

The watchlist task in risk_summary.tasks reports the aggregate outcome: watchlist_no_hits (a success result) or watchlist_hits (a failure result).
A top-level watchlists array lists each individual hit — the list it came from, the listed entity, and which submitted field drove the match. It is an empty array when there are no hits.

A hit is not an automatic decline

watchlist_hits means a submitted name resembled a listed entity — always review it before acting. A common false positive is a business or person that shares a name with a sanctioned entity but is someone else entirely.

Watchlist screening must be enabled

The watchlist add-on must be enabled for your account. Contact us to discuss access.

Screening a business

Add attrs=watchlist to any verify or identify request. The business is matched and verified as usual, and the watchlist screen runs over the matched legal entity and the people registered on it. You can request other add-ons in the same call — for example attrs=watchlist,tin_verification.

curl --request POST 'https://api.enigma.com/v2/kyb/?package=verify&attrs=watchlist' \
--header 'Content-Type: application/json' \
--header 'x-api-key: YOUR-API-KEY' \
--data-raw '{
    "name": "Acme Corp",
    "address": { "city": "New York", "state": "NY" }
}'

The matched business comes back in data, and the watchlist task appears in risk_summary.tasks alongside the usual business and identity tasks. When a submitted name matches a list, the watchlist task returns watchlist_hits and each hit is listed in the top-level watchlists array. Here the business name matched a debarment listing:

{
  "risk_summary": {
    "tasks": [
      { "task_name": "name_verification", "status": "success", "result": "name_verified" },
      { "task_name": "watchlist", "status": "failure", "result": "watchlist_hits" }
      // ...remaining business and identity tasks
    ]
  },
  "data": {
    "registered_entities": [ { "id": "350806dc-5617-7c57-0000-10c000000000", "names": [ { "name": "ACME CORP" } ] } ],
    "brands": [ { "id": "5f53e079-c66a-487e-8a9d-08efc39652ee" } ]
  },
  "watchlists": [
    {
      "id": "enigma/worldbank/WB_872",
      "match_confidence": 0.92,
      "watchlist_entity": {
        "watchlist_name": "World Bank",
        "entity_type": "legal_entity",
        "full_name": null,
        "organization_name": "ACME CORP LIMITED",
        "dob": null,
        "full_address": null
      },
      "matched_fields": { "name": "ACME CORP" }
    }
  ]
}

When nothing matches, the watchlist task returns watchlist_no_hits (a success result) and watchlists comes back as an empty array ([]).

Screening a person on its own

To screen an individual without matching a business, submit a request whose body contains only a person object, with attrs=watchlist:

curl --request POST 'https://api.enigma.com/v2/kyb/?attrs=watchlist' \
--header 'Content-Type: application/json' \
--header 'x-api-key: YOUR-API-KEY' \
--data-raw '{
    "person": {
        "first_name": "Jane",
        "last_name": "Smith"
    }
}'

The response keeps the standard KYB envelope. Because there is no business to match, data.registered_entities and data.brands come back as empty arrays and the standard business and identity tasks report their not-verified results; the individual's hits are returned in the top-level watchlists array. Here the submitted name is a close match to a listed person — a failure result that needs review, not an automatic decline:

{
  "risk_summary": {
    "tasks": [
      { "task_name": "watchlist", "status": "failure", "result": "watchlist_hits" }
      // ...standard business and identity tasks, all reporting not-verified
    ]
  },
  "data": {
    "registered_entities": [],
    "brands": []
  },
  "watchlists": [
    {
      "id": "ofac/sdn/58210",
      "match_confidence": 0.87,
      "watchlist_entity": {
        "watchlist_name": "SDN",
        "entity_type": "person",
        "full_name": "JANE SMITHE",
        "organization_name": null,
        "dob": null,
        "full_address": null
      },
      "matched_fields": { "person_name": "JANE SMITH" }
    }
  ]
}

For the full hit shape and every field it can carry, see watchlist hits.

A person-only screen enforces a strict contract — each of these returns HTTP 400:

attrs other than exactly watchlist. When only a person object is provided, attrs must be exactly watchlist — a request with extra attrs, or with no attrs at all, is rejected.
Any business input (name/names, address/addresses, website/websites, or tin/tins) alongside the person. That is a business request, not a person screen.

The package parameter is optional for a person-only screen — the watchlist screen runs whether or not a package is named, and the package affects only how the request is metered.

When to Choose Identify

Marketplace Seller Verification

When onboarding sellers to your marketplace, you need to confirm they're real businesses and match submitted information to public records—but registration status may not be critical for your risk model.

Example workflow:

Seller submits "Brooklyn Pizza" as business name
Identify matches to "JPR Holdings LLC" in state records
Returns registration data, address, and entity type
You verify name and address match your application
Seller approved for basic marketplace access

Why Identify works: You're validating identity and enriching your seller database, not making compliance decisions based on active state filing status.

B2B SaaS Onboarding

SaaS platforms need to verify business customers are legitimate and match submitted details—primarily for fraud prevention and data quality, not regulatory compliance.

Example workflow:

Customer signs up with company name and address
Identify confirms business exists in public records
Returns entity details for account enrichment
You populate CRM with verified business information
Customer onboarded with high confidence in identity

Why Identify works: You need accurate business data for your systems, not compliance certification of registration status.

When to Choose Verify

Payment Processing

Payment processors must verify merchant legitimacy and compliance status to meet network requirements and prevent fraud. Active state registration is often required.

Example workflow:

Merchant applies with business name and EIN
Verify confirms business is actively registered
Returns status: "Active" with domestic registration confirmed
You validate merchant meets underwriting requirements
Merchant approved for payment processing

Why Verify is required: Payment networks and acquiring banks often require confirmation of active state registration. Status fields prove compliance.

Business Onboarding

Enterprises, especially financial institutions, can reduce risk and facilitate compliance by verifying the identity and standing of the businesses that they serve.

Example workflow:

Business applies for checking account
Verify confirms active registration status
Returns jurisdiction type and registration state
Account opened with full audit trail

Why Verify is required: Bank compliance teams must document active registration status for regulatory audits.

Business Lending

Lenders need to verify borrower legitimacy and registration status as part of underwriting—lending to dissolved or suspended entities creates legal and credit risks.

Example workflow:

Business applies for $50,000 line of credit
Verify confirms active registration and jurisdiction
Returns status: "Active - Good Standing"
Underwriter confirms entity is legally operating
Credit decision made with confidence in entity legitimacy

Why Verify is required: Lending agreements require active legal entities. Status fields protect against lending to dissolved or suspended businesses.

KYB Packages

Attribute and Task Comparison

Add-On Tasks

Attribute-only requests (`products`)

Watchlist Screening

Screening a business

Screening a person on its own

When to Choose Identify

Marketplace Seller Verification

B2B SaaS Onboarding

When to Choose Verify

Payment Processing

Business Onboarding

Business Lending

FAQ

Is there a difference in response time between the packages?

Can I add TIN, EIN, or SSN verification to Identify?

Can I add Watchlist (OFAC Sanctions) screening to Identify?

How do I switch packages?

How do I screen just a person against watchlists?

Screening a person on its own​

Screening a person on its own