Sanctions and exclusions, on the entity, not just the list.

Screening is usually a string-matching exercise against a dozen separate lists. Amalgament flips it: exclusions, debarments, and sanctions attach to the resolved entity, so the question is not 'does this name appear on a list' but 'is this actual company flagged anywhere.' That distinction is the difference between noise and signal.

What's in the record

• Federal exclusion and debarment records
• Sanctions listings at the business level
• Effective dates and listing agencies
• Entity joins so flags appear on the company profile

Where it comes from

Federal exclusion and sanctions sources, business-level only. Individual persons on those lists are excluded from the platform by design.

What people build with it

KYB and compliance flows that must screen before onboarding, marketplaces keeping flagged entities out, and procurement systems checking vendors against debarment lists.

One call

curl -H "X-API-Key: $OPENFOLIO_KEY" \
  "https://api.amalgament.com/search?q=services&dataset_type=exclusion"

Common questions

Is this a substitute for a full compliance program?

It is a data layer for one, not the whole program. Amalgament gives you clean, joined screening data; your compliance process decides what to do with a hit.

Why business-level only?

Amalgament deliberately excludes person-level records across the platform. That keeps the data useful for KYB while staying clearly outside consumer-reporting use.

More record types: Businesses · Property · Courts · Filings · All record types