Case study

How I built an automated sanctions screening system for a $500M investment fund

A real estate investment trust needed to screen investors against global sanctions lists before accepting their capital. Here's how I designed and built the solution — from regulatory research to production deployment.


The problem

A real estate investment firm on the U.S. West Coast operates a private REIT. They accept capital from individual and institutional investors to acquire and manage properties. A major financial institution serves as their custodian.

Before any investor can place funds into the trust, the firm must verify that the person or entity does not represent a regulatory, legal, or reputational risk. This isn't optional — it's a legal obligation.

OFAC operates under strict liability. That means you can be fined even if you didn't know you were accepting money from a sanctioned entity. Fines can reach millions of dollars per violation.

The firm had no documented, repeatable process for investor screening. If a regulator ever asked "what did you do to verify this investor?" — there was no defensible answer. The existing process was manual, slow, inconsistent, and left no evidence behind.

They had identified the right tool — LSEG World-Check, the same sanctions database used by the world's largest banks. What they didn't have was someone who could take that tool and integrate it into their actual operations.

What I had to learn first

I'm not a compliance officer. I'm a builder-architect who designs and builds digital operations — APIs, integrations, automation systems. But this project required me to understand the why before I could build the what.

I dove into OFAC enforcement and how strict liability works. I studied KYC and AML requirements for investment funds, and learned how FinCEN is actively expanding regulations in real estate. I learned the critical distinction between sanctions (legally prohibited), PEP flags (elevated risk requiring due diligence), and adverse media (reputational concern) — because each category demands a different operational response.

Most importantly, I had to understand what the client's legal team would need if a regulator came knocking. The system had to generate evidence that could withstand scrutiny: who screened, what was found, what was decided, and why.

This research phase wasn't just homework — it shaped every design decision that followed.

The architecture

Database & UI
Airtable
Investor records, screening status, operational interface
Orchestration
Zapier
HMAC auth, API calls, result parsing, routing
Screening engine
LSEG World-Check
Sanctions, PEP, adverse media — 60+ countries
1
New investor record is created in Airtable
2
Zapier triggers and prepares the API request with HMAC-SHA256 signature
3
World-Check screens the name against global sanctions and watchlists
4
Results are parsed and categorized: sanctions (block), PEP (review), clear (approve)
5
Airtable is updated with status, match details, and risk level
6
A PDF compliance dossier is generated and attached to the investor record

The hard parts

HMAC-SHA256 authentication. World-Check doesn't use simple API keys. Every request must be cryptographically signed — including the request target, host, date, content type, content length, and the full request body. If any character is off, the request fails. This was my first time implementing HTTP Signature authentication, and the precision required was unforgiving.

Interpreting screening results. When you screen a name, the API might return five results. Those aren't five confirmed risks — they're potential matches based on name similarity. The system needed to surface the right information for each match without overwhelming the user, and to separate true risks from false positives.

Two modes of operation. Quick Screening handles the 80% case where the investor has no flags at all — enter a name, get an immediate answer. Detailed Review lets analysts investigate each potential match, review full watchlist records, add resolution comments, and record documented decisions.

The compliance PDF pipeline. Reports are generated asynchronously — you request them, poll for completion, download them as ZIP files, and upload them to the client's document storage. Each step needed error handling and retry logic.

What I delivered

Automated screening from the investor database
Intelligent categorization of results
Two operational modes for different needs
Documented decisions with timestamps
PDF audit trail per investor
Ongoing monitoring capability

The firm went from having no documented compliance screening process to having an automated, auditable system that matches the standards used by major financial institutions — built entirely with no-code/low-code tools and a single custom API integration.

What this project taught me

This wasn't just a technical integration. I had to learn a regulated domain from scratch and understand the legal implications of every design decision. I had to design for auditability — in a regulated environment, it's not enough for the system to work, it has to prove it works.

I had to bridge the gap between a powerful financial-grade API and a non-technical operations team. And I had to build trust before building features — the training guide I wrote was as important as the code.

This is the kind of work I do: take a complex business requirement, understand the domain deeply enough to make the right design decisions, and build a solution that a real team can actually use — end to end, from research to production.