yente-cli mirrors the Python SDK surface and serves one-off lookups, shell pipelines, and LLM-agent automations
Back in May, we wrote about some of the ways LLMs are changing screening, including how a shift towards narrative matching is redefining the compliance industry's data needs. “Most compliance teams are still working out whether they want to use LLMs at all,” we wrote at the time, “let alone how”.
Fast forward a few months, and it feels like that future was nearer than we anticipated.
Agentic LLMs have emerged as the industry’s answer to surging screening volumes and false positives, driven by an increasingly prescriptive regulatory landscape. Agents are no longer just reading watchlists, but are starting to run workflows: pulling customer records, running screening checks, flagging anomalies, and handing analysts a clean case file so they can weigh in on judgment calls and sign off.
This new reality raises a much more practical question than "should compliance teams use AI?” If an agent is going to call your screening logic, the question you need to ask is what exactly is it calling, and is it able to show its workings?
We built yente-client to bridge that gap. It's a toolkit with three doors: an SDK for a developer, a CLI tool for an analyst, and an MCP server for an LLM agent. Each layer offers a different way to call the API, but all three are powered by the same open matching engine. Whether a response arrives as CLI text, an SDK object, or an agent's tool result, it's a FollowTheMoney (FtM) entity underneath — an ID, a schema, and properties that link out to other entities, forming one connected graph.
What is yente-client?
yente-client is the official Python-side tooling layer for talking to yente, our open-source screening API service that provides functions to search, retrieve, or match people, companies, or vessels that are subject to international sanctions.
The toolkit bundles three things:
It collapses several jobs that would ordinarily be handled separately into a single package. Before, using OpenSanctions meant hand-rolling API calls or checking names against a watchlist one by one. We built an SDK, CLI, and MCP server on top of the same matching engine, so a team gets a tested, consistent answer instead of having to assemble that capability from scratch.
Three ways to call the API, powered by the same open matching engine and FtM data model
Layer 1: The Python SDK
The SDK is a Python library that wraps the OpenSanctions matching API, so you call a method instead of building a request by hand. You describe who you're checking — a name, a birth date, whatever you have — pass it to client.match(), and get back a ranked, scored list of candidates.
It works the same way against the hosted API or a self-hosted yente instance — simply swap an api_key for a base_url. The latter means you’re not locked out of using the SDK if you can't send customer Personally Identifiable Information (PII) to a third party, as you can run the whole stack internally instead.
Layer 2: The command-line tool (CLI)
yente-cli provides the same matching and search operations, but this time from the terminal.
It’s a command-line tool for quick, ad-hoc lookups without writing a script. This is useful for running a quick check or for scripting into something that runs on its own, like a nightly re-screen of your customer list.
With defined output formats and exit codes, it drops cleanly into shell scripts, cron jobs, or CI pipelines, so a nightly customer list check or a CI step can run the same matching logic the SDK exposes to developers.
Layer 3: The MCP server
yente-mcpexposes match() and search() as tools an AI agent can call directly, rather than a person triggering each request by hand. An agent can then handle screening as one step in a larger workflow – for example, checking a batch of new vendors against sanctions lists and flagging anything over a risk threshold – while each tool call still produces a clear, auditable record of what was checked and what came back.
We’ve built this to run on your own infrastructure first: right now, the MCP app runs as a simple local service, not a hosted endpoint. We'll explore a public endpoint later this year.
Who is yente-client for?
- Engineers at banks, fintechs, and crypto platforms building or maintaining in-house KYC/AML onboarding and screening systems.
- RegTech vendors who want to integrate OpenSanctions data into their product without reinventing an HTTP client.
- Compliance engineering teams running batch re-screening jobs — for instance, nightly checks of an entire customer book against freshly updated sanctions lists.
- Teams building agentic compliance workflows, who need screening exposed as a clean, callable tool rather than a manual step.
The industry shift
Up to this point, we've been intentionally quiet about the agentic solutions flooding the market and where our tech stack fits in. Some vendors are promising fully autonomous decisioning — agents that screen, judge, and close cases without a human in the loop. Right now, we're not building toward that, and we don't think the industry should be either.
Data quality and transparency remain our priority, which is exactly why yente-client is built to help teams scale without letting data provenance or explainability take a back seat. As compliance workflows keep shifting toward agentic tooling, one distinction will become increasingly important: not just that a match was flagged, but why.
We'll continue to fine-tune and build upon this tooling, but in the meantime, we're inviting you to battle-test yente-client — we want to hear what you think. Start with the API itself, self-hosted or via OpenSanctions' hosted version, then reach for yente-client once you're ready to bring it into code, a CLI workflow, or an agent.
Documentation here.
Useful links
