Noble Sight
Which of these releases does your integration resemble?
The four pages in this series each quote an OFAC enforcement release and prove the control that answers it. Most of those controls only fire when the integration sends the field they need: an exact name-and-date-of-birth match needs date_of_birth, Pegasus's phone number needs ids, CoinList's Crimean address needs address, Interactive Brokers' second reviewer needs a named analyst. Noble holds every screening request and every alert action a tenant has ever sent, so it can answer the question from the records rather than from a questionnaire. One GET request, your own key, seven controls, each with a status.
Endpoint: GET /v1/account/coverage, documented in the API reference and the changelog entry of 2026-10-24. Every quotation below is verbatim from the OFAC release it names; each links to the page in the series that proves the control. Part of Noble's enforcement series.
KEY to a Noble API key. A free-tier key works; keys are invite-only while Noble is in beta (sales@noblesight.io). The report covers the key's account, so a key that has never screened anything reports every control as not_applicable until it does. The three screenings further down change the report, which is the point of them.
Run the report
No parameters: the last 90 days. from and to are inclusive UTC days; a window longer than 366 days is refused with invalid_parameter rather than silently truncated. Screenings are the account's own api and batch calls that completed. Monitoring re-screens are the server's work, not the integration's, and are not counted.
Run it: the default window
curl -s https://api.noblesight.io/v1/account/coverage -H "X-API-Key: $KEY"
Run it: a quarter
curl -s https://api.noblesight.io/v1/account/coverage'?from=2026-07-01&to=2026-09-30' -H "X-API-Key: $KEY"
The fields: inputs, alerts, and one controls[] entry per release
"window": { "from": "2026-07-27", "to": "2026-10-24" },
"screenings": 118852,
"inputs": {
"name": { "count": 113180, "share": 0.952 },
"date_of_birth": { "count": 30673, "share": 0.258 },
"country": { "count": 44858, "share": 0.377 },
"location": { "count": 6302, "share": 0.053 },
"address": { "count": 23, "share": 0.0002 },
"entity_type": { "count": 12607, "share": 0.106 },
"identifiers": { "count": 5680, "share": 0.048 },
"lists": { "count": 7280, "share": 0.061 },
"as_of": { "count": 40, "share": 0.0003 }
},
"alerts": {
"opened": 42594, "closed": 9,
"closed_by_named_analyst": 2, "closed_by_api_key": 7,
"four_eyes_closures": 2, "open_overdue": 42064, "active_team_members": 2
},
"controls": [
{ "id": "list_versions", "status": "active", "share": 1,
"release": "Bank of America, N.A. — OFAC, 2026-10-13",
"page": "https://noblesight.io/enforcement/bank-of-america-2026",
"requires": [],
"guidance": "Nothing to send: list_versions is on every response; read GET /v1/lists for freshness." },
{ "id": "exact_name_dob", "status": "partial", "share": 0.271, "requires": ["date_of_birth"],
"guidance": "Send date_of_birth (YYYY-MM-DD) on individual screenings so an exact name-and-DOB match is scored as one and a mismatch is recorded as a signal." },
{ "id": "no_suppression", "status": "active", "share": 1 },
{ "id": "lookback", "status": "partial", "share": 0.0003, "requires": ["as_of"] },
{ "id": "identifiers", "status": "partial", "share": 0.048, "requires": ["ids"] },
{ "id": "geography", "status": "partial", "share": 0.377, "requires": ["country", "location", "address"] },
{ "id": "named_actors", "status": "partial", "share": 0.222, "requires": ["X-Actor", "POST /v1/team"] }
]
# window too long
{ "type": "invalid_request_error", "code": "invalid_parameter", "param": "from",
"message": "window is 661 days; at most 366" }
Captured from production on 2026-10-24 for Noble's own test account, shares rounded here for width; the API returns them in full. Every control carries release, page, requires and guidance; the listing above trims the repeats. This account is a test harness that screens mostly bare names, and the report says so: five of seven controls partial. A report that only ever said active would be worth nothing.
Seven controls, each tied to the words OFAC used
A control is active when at least nine screenings in ten carry what it needs, partial when some do, inactive when none do, and not_applicable when there was nothing in the window to measure. Two controls need nothing from the integration and are active for any account that screened at all; they are listed so the report has the same shape for everyone. The share is measured against the screenings a control could apply to: a date of birth against screenings that carried a name, a named analyst against closures.
Every screening names the list versions it ran against
Between May 24 and June 28, 2023, due to human error by a third-party vendor, the sanctions watchlist file Bank of America used to perform sanctions screening was not updated to reflect changes to OFAC’s List of Specially Designated Nationals and Blocked Persons.
Enforcement Release, October 13, 2026, page 3.
Every /v1/screen response carries list_versions[] with each list's publish date, so the staleness Bank of America discovered after five weeks is visible on every decision. There is nothing to send, which is why this control reads active for every account that has screened.
An exact name and date of birth is scored as one and alerts at 100
Due to a design flaw in its alert prioritization logic, Bank of America’s sanctions relationship screening system classified alerts associated with individual customers whose name and date of birth both matched exactly those of a blocked person as low- or medium-priority, rather than high-priority.
Enforcement Release, October 13, 2026, page 2.
Noble has no priority tier to misclassify into; an exact match scores 100 and opens an alert. But it can only compare a date of birth it was given. The share is the fraction of named screenings that carried date_of_birth. An integration that screens individuals by name alone has the match this control describes and does not know it.
Every threshold match opens an alert; a past disposition never suppresses a new one
Despite alerting in Bank of America’s system, the payments were released automatically due to an “alert suppression rule,” a screening function used by Bank of America that automatically “suppressed” alerts in certain circumstances—for example, if an alert was based on the exact same criteria as an alert that a Bank of America analyst manually dispositioned as a false positive in the past.
Enforcement Release, October 13, 2026, page 2.
There is no suppression rule to configure. A threshold match opens an alert on every screening, and closing one takes a person and a reason code. Active for every account that has screened; the report lists it so the absence is on the record, not assumed.
Lookbacks screen against the lists as they stood on any past date
Bank of America initially performed only a single, narrowly tailored lookback and did not identify the full scope of its payment activity involving blocked banks until after OFAC directed it to provide information about recent lookbacks it had conducted in a January 2025 administrative subpoena.
Enforcement Release, October 13, 2026, page 2.
A screening with as_of runs against the lists as they were on that date, and POST /v1/export/replay re-runs stored decisions the same way. This is the one control a low share does not condemn: a lookback is an event, not a daily habit. The share tells you whether the capability has ever been exercised from this account, which is the question an examiner asks. Lookbacks reach back to the start of Noble's own list history, reported per list by GET /v1/lists as history_from; an earlier as_of is refused, never answered clean.
Identifiers on the document are screened, not just the name
Those documents identified the shipper using Youli’s new post-designation name, “Huizhou Youli Fushi Co., Ltd,” but included Youli’s unchanged telephone number as OFAC identified it on the SDN List.
Enforcement Release, October 9, 2026, page 2. Pegasus's own policy called for screening “parties’ name, address, email, phone, and other information” (page 2).
A phone number, email address, registration number, wallet address or IMO number in ids[] is screened in the same request as the name, and a hit names the identifier in matched_via. The share is the fraction of screenings that sent any identifier at all. Pegasus had the phone number in hand and screened the name.
Declared geography raises the embargo advisory, including a Crimean city in the address
However, CLM’s screening procedures failed to capture users who represented themselves as resident of a non-embargoed country but who nevertheless provided an address within Crimea.
CoinList Enforcement Release, December 13, 2023, page 1. The release continues: because “Russia” was in the country field, the tool “failed to recognize that “Crimea” or a city name in Crimea, provided in another data field, indicated likely residence in Crimea.” Poloniex's remediation was a “Crimean city/region keywords list” (page 3).
Noble reads country, location.region, location.city and the free-text address, and jurisdiction_nexus.source names which field decided. The share counts screenings that sent any of them. An integration that sends only the drop-down country has CoinList's gap exactly; one that sends nothing has no embargo control at all.
Alerts are closed by named analysts, with a second one above 90
IB staff, however, incorrectly dispositioned the sanctions alert as a false positive.
Enforcement Release, July 15, 2025, page 5. Among IB's remedial measures: “implementing a second-level review of an increased scope of screening results” (page 7).
This is the one control measured on alert closures rather than screenings. A closure with X-Actor set to a registered team member is a named closure; at score 90 and above the closer must differ from the last analyst who acted. The share is named closures over all closures. An account that closes alerts with the bare API key has one anonymous reviewer, which is the IB shape with the name removed. alerts.four_eyes_closures, open_overdue and active_team_members sit beside it.
Move the numbers yourself
A report that cannot be moved is a brochure. These three screenings each carry one input the report measures. None of them matches anyone, so none opens an alert; each adds one to a count. Run them, then run the report again.
A screening with a date of birth
curl -s -X POST https://api.noblesight.io/v1/screen -H "X-API-Key: $KEY" -H "Content-Type: application/json" -d '{"name":"Zzyxx Coverage Probe","date_of_birth":"1970-01-01"}'
A screening with an identifier
curl -s -X POST https://api.noblesight.io/v1/screen -H "X-API-Key: $KEY" -H "Content-Type: application/json" -d '{"name":"Zzyxx Coverage Probe","ids":[{"number":"+1 415 555 0100"}]}'
A screening with a country and a free-text address
curl -s -X POST https://api.noblesight.io/v1/screen -H "X-API-Key: $KEY" -H "Content-Type: application/json" -d '{"name":"Zzyxx Coverage Probe","country":"GB","address":"10 Downing Street, London SW1A 2AA"}'
Then read the report again
curl -s https://api.noblesight.io/v1/account/coverage -H "X-API-Key: $KEY"
Before and after, from inputs
# before
"date_of_birth": { "count": 30673 }, "identifiers": { "count": 5680 }, "address": { "count": 23 }
# the three screenings
"request_id": "req_6d2fff49417f4645", "summary": { "verdict": "no_significant_match" }
"request_id": "req_f94d4fa6947ffae4", "summary": { "verdict": "no_significant_match" }
"request_id": "req_b0483b09fe5350a2", "summary": { "verdict": "no_significant_match" },
"jurisdiction_nexus": { "source": "country", "evaluated": "GB", "status": "no_determination" }
# after
"date_of_birth": { "count": 30674 }, "identifiers": { "count": 5681 }, "address": { "count": 24 }
Captured from production on 2026-10-24. The counts move on the next read because the report is computed from the screening record, not from a nightly rollup. The third screening also shows the geography control doing its reading: the nexus names the field it evaluated and reports no determination for a British address, which is the correct silence.
What this report is not. It counts whether a field was sent, not whether it was right; a date_of_birth of 1900-01-01 on every record counts as sent. It cannot see fields the integration holds but does not send, which is exactly the gap it exists to surface. It counts the account's own api and batch screenings and ignores the server's monitoring re-screens, so a portfolio under monitoring does not inflate it. It is one account's view: a bank with several keys reads each.
It is not a compliance opinion. active on all seven controls means the integration sends what the controls need; it says nothing about the program around them. Quotations are OFAC's; the mapping from each release to a control is Noble's reading of the public document.
Run it against your own key
The report is on every tier, including free. The same object is the coverage_report tool on Noble's MCP server, so an agent can answer "are we sending what Bank of America's screen was missing?" from the records.