AML & sanctions screening SaaS
Pactuary screens customers and counterparties against sanctions and PEP lists, monitors them after onboarding, watches transactions for known typologies, and keeps every decision ready for an auditor. Built for compliance teams in Türkiye.
An independent product by Burak Esenoglu. Screens show a synthetic demo bank.
Demo
Search, result, entity detail, a reasoned decision, and approval by a second analyst. Recorded on the synthetic demo bank.
The problem
Modules
People and companies are screened against live OpenSanctions data and the institution's internal lists in parallel. Results show the risk level, topics, match score and the exact source lists. The risk level comes from what the record is (sanction, crime, PEP), not from how similar the name looks.
Aliases, identifiers, sanctions programmes and source documents on one page. The analyst records a true match, a false positive or an escalation, and a reason is always required.
Up to 100 subjects in a single request, with optional birth year and country to sharpen matching. A whole portfolio gets screened in seconds.
Five typologies: single-threshold breach, high-risk country (FATF lists), counterparty sanctions/PEP match, structuring and velocity. Real-time rules run on ingest; pattern rules run every night. TCMB exchange rates are applied, and a missing rate is never guessed.
Monitoring and transaction alerts share one inbox. With four-eyes on, a true match waits for a second, different analyst, and self-approval is rejected by the system.
A 0–100 score from four weighted factors (screening signal, transaction pattern, country and channel). Each factor shows its reason, so the score can be explained.
Each typology can be switched on or off and tuned per institution. Invalid settings fall back to safe defaults, so a broken setting never silently turns a rule off.
The portfolio is re-screened every night; only new matches raise alerts.
Append-only decisions with snapshots and a one-click audit file per case.
Scoped API keys for screening and transaction ingestion, plus HMAC-signed webhooks.
Company-level isolation, three roles and separate quota pools per module.
Provider-ready (stub): the interface, data model and screen are built; no news vendor is connected yet.
On the roadmap.
How it works
An analyst searches, a portfolio is uploaded, or a core system posts a transaction over the API.
Sources are queried in parallel; each one reports its own status and latency.
Typology rules and risk scoring turn matches and patterns into prioritised alerts.
An analyst records the decision and reason; with four-eyes on, a second analyst approves it.
The decision, its snapshot and the audit file stay unchanged for the auditor.
Compliance by design
Each source reports its own status. If every source fails, the API returns an error, never an empty list. A rule that could not run is reported as unavailable.
Per institution, a true match needs a second approver, and the same person cannot approve their own decision.
Decisions are never edited. A change is a new record that points to the old one, with a snapshot of the data at decision time.
Every customer has an explained 0–100 score, and country risk follows the FATF black and grey lists.
A sanctions record is critical even with a modest name score; a PEP is medium even with a perfect one.
Without a TCMB rate, a transaction waits as "pending FX" and amount rules run once the rate arrives.
Designed around MASAK and FATF requirements. Not a certification and no compliance guarantee: thresholds such as TRY 75,000 are starting values each institution should validate.
Matching benchmark
100 labelled queries ran through the product's batch screening path (OpenSanctions /match, threshold 0.7, sanctions collection) in October 2026.
Where the hits came from
Security & architecture
Every API request verifies the JWT on the server; unverified cookie reads are not used.
Keys are stored as SHA-256 hashes, shown in full once, scoped to an action and revoked without deletion.
All queries are scoped by company. Database row-level security denies direct data-API access.
Quota is checked before any paid call and deducted with conditional SQL, so concurrent requests cannot overspend.
Timeouts, retries with backoff and jitter, Retry-After support, a TTL cache and request coalescing.
Scheduled jobs refuse to run without their secret, and the health check reports the missing configuration.
Stack
Developer API
Send a name with optional birth date and countries. Every response says which sources answered, so your system can tell "clear" from "incomplete". The example uses a fictional customer and a fake key.
POST /api/v1/screening
Authorization: Bearer sk_test_EXAMPLE_ONLY_not_a_real_key
Content-Type: application/json
{
"name": "Defne Örnekoğlu",
"birthDate": "1987",
"countries": ["TR"],
"category": "individual"
}{
"results": [],
"total": 0,
"totalRelation": "eq",
"highestRisk": null,
"providers": [
{ "provider": "opensanctions", "ok": true, "resultCount": 0, "latencyMs": 184 },
{ "provider": "local", "ok": true, "resultCount": 0, "latencyMs": 289 }
],
"remainingQuota": 4210
}{
"error": "…",
"errorCode": "TIMEOUT",
"providers": [
{ "provider": "opensanctions", "ok": false, … },
{ "provider": "local", "ok": false, … }
]
}FAQ
From OpenSanctions, queried live through its hosted API. The default scope is 95 sanctions lists, including OFAC SDN, the UN Security Council list, EU and UK sanctions and the MASAK asset-freezing list. Institutions can add their own internal lists.
No. It is designed around MASAK and FATF requirements, but no certification exists for this kind of tool and none is claimed. Each institution validates thresholds and procedures with its own compliance function.
Risk comes from what a record is, not the name score. Optional birth year and country sharpen matching, and a false-positive decision is remembered, so the same record is excluded next time for that subject.
The analyst sees which source failed. If every source fails, the request returns an error instead of an empty list, because an empty list would read as "clear".
The adverse media module is provider-ready: its interface, data model and screen exist, and it shows sample data until a news vendor is connected.
The repository is private. I am happy to walk through the code and the design decisions in an interview.
Pricing is not published. Contact us for a demo and a conversation about your volumes.
A 30-minute walkthrough: screening, a structuring alert, the four-eyes flow and the audit file. Pricing: contact us.