I gave Claude four compliance tools and one prompt. It built the due-diligence memo itself.

This is an experiment, and I want to be precise about what it does and does not prove. I connected Claude to four live compliance data sources through the official Apify MCP server, gave it a single plain-English instruction, and watched to see whether it could run a real due-diligence check end to end: decide which sources to query, run them, cross-reference the results, score the risk, and hand back a memo where every claim points at a source.

No mocked screens. Every registry record, sanctions hit, and SEC filing below is a real lookup against a live source, captured from an actual chat, with the Apify run ID printed next to it so you can reproduce it. The interesting part is not that a tool returned data. It is that nobody told Claude which tools to call or in what order. It read the request, picked the checks, and organized the evidence on its own.

The bold version of the pitch: due diligence in one prompt. You name a company, the agent builds the dossier.

The four tools I wired in

A due-diligence check on a counterparty is really four separate questions, each answered by a different authority:

1. Is the legal entity real and currently active? A name on an invoice proves nothing. Companies dissolve, get wound up, or never existed under the name on the paperwork.
2. Is the party on a US sanctions list? Wiring money to an entity on the US Treasury's OFAC list is a strict-liability federal offense. "We didn't know" is not a defense.
3. Is it on the EU list too? A second jurisdiction either corroborates a hit or widens the exposure.
4. Does it file publicly, and do the identifiers match? A company that files a 10-K with the SEC leaves a paper trail you can cross-check against the registry.

I connected one Apify Actor for each, all exposed to Claude through a single MCP endpoint:

• The Sunbiz Florida Business Registry & Officers Scraper (the full registry record: legal name, status, document number, officers, registered agent, and event history).
• The OFAC Sanctions List Screening Scraper screens a name against the Specially Designated Nationals (SDN) list and returns programs, aliases, addresses, and linked entities.
• The EU Consolidated Sanctions List Scraper (the same screening against the European list, with regulation references and identifiers).
• The SEC EDGAR Filings Scraper pulls a company's filings (10-K, 10-Q, 8-K) with the CIK, accession numbers, and filing dates.

Four tools, one config line, no glue code. Then I opened a chat and typed a sentence.

One prompt, and the agent decided the rest

I picked a clean subject on purpose for the first run: Publix Super Markets, the Florida grocery chain. A real, active, Florida-incorporated company that also happens to file with the SEC, a good test of whether the agent would reach for the right combination of tools without being told.

Here is the entire instruction I gave it, and what happened next:

I did not name a single tool. Claude decomposed the request into four checks and ran them in a sensible order (registry first to establish the entity, then both sanctions lists, then SEC filings), narrating its reasoning between calls. Every call is a real Apify run:

• Sunbiz → run pDNlZeA1aBU6oCQrS: ACTIVE, PUBLIX SUPER MARKETS, INC., Florida Profit Corporation, document #112252, filed in 1921, with named officers (CEO Kevin S. Murphy, President John L. Goff, Jr., CFO David P. Phillips).
• OFAC → run GSsSWcL3Kd2CoN63s: 0 matches.
• EU consolidated list → run mOYdsujWKycKzbakB: 0 matches.
• SEC EDGAR → run PDMwwh0FVfgzytjCu: a 10-K filed 2026-03-02 for the fiscal year ending 2025-12-27, under CIK 0000081061.

Then it did the thing I was actually watching for. It noticed that the EIN on the SEC filing (59-0324412) is an exact match to the FEI number on the Florida registry record. The same legal entity, confirmed by two independent government sources. Nobody asked it to reconcile identifiers across databases. It reasoned that a cross-check was worth doing and did it.

The scored dossier

Data is not a decision. The last step, and the one that usually eats an analyst's afternoon, is turning four raw results into something you can attach to a file and defend to an auditor. I asked Claude to score the risk and write it up.

It scored Publix LOW and laid out the reasoning as a table where every row carries the run ID behind it: registry PASS, OFAC CLEAR, EU CLEAR, SEC VERIFIED, and the identity cross-check MATCH. The recommendation is "proceed with onboarding," explicitly subject to human sign-off.

That last clause is not decoration. The score is a heuristic the agent applies to evidence it gathered; it is a starting point for a human, not a verdict that replaces one. What the agent removed was the mechanical labor (the tab-switching, the copy-paste, the risk of skipping a check under deadline pressure), not the judgment.

The contrast: what a bad name looks like

A clean result only means something if the same workflow catches a dirty one. So I ran the identical instruction against a name I knew would be a problem: Rosoboronexport, a Russian state arms exporter.

The agent screened the US list first, hit a match, and (instead of stopping) reasoned that a second jurisdiction was worth confirming before it reported. Both runs came back positive:

• OFAC → run MLnvX5XE9E8vZYPK7: 1 SDN match. Listed as ROSOBORONEKSPORT OAO, under three programs (UKRAINE-EO13662, RUSSIA-EO14024, IRAN-CON-ARMS-EO), linked to State Corporation Rostec, at 27 Stromynka Ul., Moscow.
• EU consolidated list → run wEU9R9n6McPW5SAfh: 1 match, reference EU.7808.66, programme UKR, designated 2022-03-15.

And again the agent did the cross-reference on its own. It noticed that both lists carry the same tax ID (7718852163) and the same registration number (1117746521452), meaning this is not a fuzzy name coincidence but the same legal entity, corroborated by two independent authorities. It scored the counterparty HIGH, returned a STOP verdict, and recommended blocking the party and escalating to legal. Everything a compliance officer needs to act, with the evidence already attached.

What the agent actually did, and what it didn't

I want to be honest about the boundary, because the interesting claim here is narrow and the overselling would be easy.

What the agent did:

• Chose the tools. From one sentence, it decomposed the task into the right four checks and picked the matching source for each. It was not following a script.
• Sequenced the work. Registry before sanctions before filings; on the sanctions hit, it confirmed a second jurisdiction before reporting rather than firing everything blindly.
• Cross-referenced identifiers. It matched an EIN to an FEI across two databases, and a tax ID across two sanctions lists, without being asked, the kind of corroboration that separates a real check from a name lookup.
• Scored and cited. It turned raw records into a risk band with a source run ID on every line.

What the agent did not do:

• It did not make the final call. LOW and HIGH are recommendations. A human still signs off on onboarding or blocking.
• It did not invent anything. Every figure came from a live source in the last few minutes, printed with its run ID. When OFAC and EU returned nothing for Publix, the agent reported "no match," not "clean," an important distinction it kept straight.
• It did not replace a compliance program. Fuzzy-name edge cases, beneficial-ownership tracing, and adverse-media checks are still human work. This automates the first, mechanical pass.

That division (the fetch and the first-pass scoring are automated, the judgment and sign-off stay human) is exactly the right one, and it is why the output is audit-ready by default instead of a black box.

Build the same agent

Everything above is reproducible today with a free Apify account and any MCP-capable client (Claude Desktop, Cursor, or your own agent):

1. Get your Apify API token from the Apify Console under Settings → Integrations.
2. Add the official Apify MCP server and list the four Actors in the tools parameter:

{
  "mcpServers": {
    "apify": {
      "url": "https://mcp.apify.com?tools=scrapers_lat/sunbiz-florida-scraper,scrapers_lat/ofac-sanctions-scraper,scrapers_lat/eu-sanctions-list-scraper,scrapers_lat/sec-edgar-filings-scraper",
      "headers": { "Authorization": "Bearer YOUR_APIFY_TOKEN" }
    }
  }
}

1. Restart the client and ask it, in plain English, to run due diligence on a company. It will pick the right tool for each question, run them, and score the result.

📌 Note: each tool call is a real Actor run billed to your Apify account, and each of these Actors is pay-per-result, a fraction of a cent per lookup. For continuous screening of thousands of counterparties, run the Actors on a schedule through the Apify API instead of one call per chat.

🏹 Extend it: the same pattern scales to any jurisdiction or check. Add UK Companies House for British entities, or a company-registry Actor for whatever market your counterparties sit in, to the tools list, and your agent covers more ground without a single new line of code.

The point of the experiment was never that a scraper can pull a record; that has been true for years. It is that a capable model, handed the right tools and one clear instruction, can now do the assembly (decide what to check, reconcile it, score it, and cite it) and leave a human with the one thing that should stay human: the decision.

The Actors used in this experiment: Sunbiz Florida Business Registry & Officers Scraper, OFAC Sanctions List Screening Scraper, EU Consolidated Sanctions List Scraper, and SEC EDGAR Filings Scraper.