Compliance

What an Examiner Asks For, and Which of It We Give You

An examination is a request for evidence. Someone asks you to show that a screening happened, when, over what, and what you did about the result. Most of the answer has to come out of your tooling, and the parts that do not have to come out of your own files.

This page is a field-by-field account of what OFACScreen records and what it does not, so that you can decide in advance where the gaps are rather than discovering them during a review. Every line is checkable against the product. Where we do not capture something, it says so in the same voice as the things we do.

What Gets Written When a Search Runs

A search from a signed-in account writes a row to the audit trail. That row holds:

The timestamp, to the second, of when the search ran.
The name searched, exactly as it was typed.
Who ran it, the user account it came from. On a team account, a member's searches are written into the owner's audit trail with the member identified.
How the search was run: single search, batch upload, API call, or automated monitoring.
How many results came back, and whether it matched at all.
The IP address the search came from, for searches run from the dashboard and for batch uploads. API calls and monitoring re-screens are recorded without one.

One Row Is Not Always One Name

This is the detail most likely to catch you out in front of a reviewer, so it gets its own section.

A search from the dashboard writes one row carrying that name, its result count, and whether it matched.
A single API call does the same, under the API search type.
A daily monitoring re-screen writes one row per monitored name, with that name, its result count and whether it matched.
A batch CSV upload writes one row for the whole file. The name on that row is the file, recorded as "Batch:" followed by your original filename, and the row is charged for the number of names in the file. The individual names, their matches and their scores are not in the audit trail; they live on the batch results page and in that run's own CSV export. The batch's API equivalent behaves the same way, recording the call as a batch of a stated number of entities.

So the audit trail proves that a file of 400 names was screened on a given day by a given user. It does not, by itself, prove which 400 names those were. If you need the names in the record, keep the batch results export.

What Is Deliberately Not Recorded

These are the things people assume are in an audit log and are not in ours. Read this section twice if you are about to put us in front of a regulator.

Which lists were in scope for a given search. The log row does not carry a list scope. Every search runs against all 8 active lists, so the scope is the same on every row, but the row itself does not assert that and cannot be used to prove which lists were live on a particular day. If your procedure needs the scope evidenced per search, the $9.99 report prints the lists by name for the screening it covers.
The matches themselves. The log records how many results came back and whether anything matched. It does not store the matched names, their scores, or the lists they came from. If you need those preserved for a specific screening, buy the report for that screening, or export the batch results, both of which do carry them.
The threshold the search ran at. The row does not record the cut-off used. Interactive and API searches run at 0.3 unless an API caller sets their own, and batch and monitoring run at 0.4, but the row does not assert which. How OFACScreen Matches Names documents the values, and that page is the substantiation for them.
The publication version of each list. Nothing in the product records which version of the SDN List was live at the moment a search ran. The report prints the list names, not their version numbers. If your procedure requires the list version to be pinned per screening, you have to record it yourself.
A review or disposition trail. There is no field for "reviewed by", "cleared as false positive", or "escalated". What a human decided about a hit lives in your own case file, not in ours.
The free public search. Searches run on the free search page are recorded anonymously and are not part of any account's audit trail, on purpose. They spend no allowance and belong to no account. If a screening needs to be in your record, run it from your account or buy the report.

The Audit Trail Export

The audit trail exports as CSV, with an optional date range, and that file is the artifact you hand over. Every plan carries it, including the 14-day trial, so you can see the export before you pay for anything. The columns are:

Date, formatted to the second.
User, but only on a team account. Where nobody else has been invited, the export has no User column at all, because there is only one person it could be. If your examiner expects to see attribution in the file itself, know this before you send it.
Query, the name searched.
Type, the search type in readable form.
Results, the number of results.
Match Found, Yes or No.
IP Address.

That is the whole file. There is no score column and no matched-name column in this export, for the reason given above.

The Batch Results Export

A completed batch run downloads as its own CSV, and this one does carry match detail, one row per screened name:

Name and Entity Type as submitted.
Match Found, Yes or No.
Top Match, the name of the single highest-scoring match.
Score, as a percentage.
List, which sanctions list that top match sits on.
Match Type, the confidence band.

Note the word top. This export carries the best match per submitted name, not every match. A name that hit six entries exports one row showing the strongest of them. The full result set for that run stays visible on the batch results page.

The CSV file you uploaded is deleted 30 days after upload. The results and the audit-trail rows survive that deletion; it is your list of counterparty names that goes, which is usually what you want. Download anything you still need inside that window.

The $9.99 Report

The report is the artifact built for handing to somebody else. For one screening it prints:

A report ID and the generation timestamp in UTC.
The name screened and the screening date.
The count of active lists checked, and every one of them listed by name at the foot of the report.
The number of matches found.
Your company name, if you entered one at checkout.
Every match, with its score, confidence band, entry type, the list it appears on, its sanctions program, and any aliases, known locations, identification numbers and remarks the source list publishes. Longer result sets show the highest-confidence matches in full and the remainder in a table that still carries each match's own name, list and score, so nothing is withheld.
When nothing matched, the same document is issued as a clearance certificate.
A permanent link on this domain showing the same document, so the recipient does not have to trust a PDF you emailed them.

What it does not carry is the publication version of each list, and it is not a legal opinion. There is a real sample report you can read in full before buying one.

What Stays Your Job

Treasury's Framework for OFAC Compliance Commitments describes five components of a sanctions compliance programme: management commitment, risk assessment, internal controls, testing and auditing, and training. A screening tool is part of one of them. The rest is yours, and no vendor can supply it:

A written policy. Who gets screened, at what points in the relationship, against what, who reviews a hit, who can clear one, and who is told when something is blocked. An examiner will ask for the document before asking for the logs.
A risk assessment. A documented view of your own exposure by customer base, product, geography and transaction type, and the reasoning that led from it to the screening you actually do.
Testing and independent audit. Evidence that somebody checked the controls work in practice. Our logs can be an input to that test; they are not the test.
Training records. Who was trained, on what, and when.
Your case files. The decision on each potential match, the reasoning, and the supporting comparison of date of birth, location and identifiers. The log will show that a name was screened and that it matched. What you concluded, and why, has to be written down by you.
Blocking and reporting. If a screening produces a genuine hit, the obligations that follow, blocking, rejecting, and the reports OFAC requires, are yours. See How to Handle an OFAC Match.

How to Check All of This

Do not take the list above on trust. On a trial account, which needs no card:

Run a search, then open the audit trail and export it. Read the header row and count the columns.
Run a two-row batch file and download the results CSV. Compare it against the results page and see what the export keeps and what it drops.
Read the sample report, or buy one for a name of your own, and check it against the section above field by field.

If you are evaluating us alongside another tool, ask the other vendor for the same field-level list, and be suspicious of an answer that has no "we do not record this" section in it.