Practical guide
OFAC batch screening: review every row, not just the upload
Plan bulk OFAC screening with stable subject IDs, explicit source coverage, per-row outcomes, safe retries, and a practical analyst handoff.
On this page
A batch is a collection of individual decisions
Bulk OFAC screening is useful for a customer portfolio, supplier list, or periodic review population. The upload itself is not the result. Each subject needs a completed outcome or a visible failure, and each candidate needs a review path.
A summary such as “batch finished” should not conceal failed rows. Preserve the submitted count, accepted count, completed count, and failed count so operations can reconcile the population.
Prepare a stable input population
Assign a stable internal reference to each customer or supplier before export. Use the correct entity type and reliable identity fields. Keep the relationship between row and internal record even when two people have the same name.
Do not flatten a corporate group into a single trading name. Similarly, do not infer that two identical spreadsheet rows are duplicates without checking whether they represent distinct internal relationships.
Keep source selection explicit
Choose the required OFAC sources or a versioned package and confirm availability. Record the coverage with the batch rather than relying on an operator’s memory of the dropdown selection. Source gaps must remain visible.
SanctionsKit supports inline subject batches and a private upload flow for larger datasets. Follow the current batch documentation for supported formats, row limits, and upload contracts. A CSV in your business system may need validated conversion; do not assume that arbitrary spreadsheets are accepted unchanged.
Treat acceptance, completion, and review separately
An accepted asynchronous request means work was accepted, not that every subject has been checked. Reconcile row outcomes after processing. Keep `potential_match`, `no_match`, and failed or incomplete rows distinct in the downstream application.
Use the idempotency rules when retrying the same submission. A new payload needs a new operation identity. Do not resubmit an entire portfolio blindly after a timeout and then merge results by name.
Design the analyst handoff before launch
Estimate how the team will handle candidates from a representative sample. Assign cases with the source record, match explanation, submitted identity, and internal reference. A reviewer should not need to rebuild that context from the original spreadsheet.
For an invented supplier file, row 18 completes with no match, row 19 returns a candidate, and row 20 fails because of invalid input. Only row 18 has a completed no-match result. Row 19 needs identity review; row 20 needs correction and a new documented attempt.
Close the batch with a reconciliation record
Document unresolved candidates, failed rows, corrections, and the owner of each remaining action. Keep the original batch and subsequent results connected. An all-green upload progress bar is not evidence that the whole portfolio was approved.
Use ongoing monitoring for retained relationships that need later rescreening. Batch screening and monitoring serve different operational purposes, and completed rescreens must be included in capacity planning.