Batch sanctions screening. Every row accounted for.

Start with the people or companies you need to check. Give every row a stable customer or supplier reference. Include the known name, subject type, and useful IDs. Leave missing facts out. Each row needs its own source IDs or package version, so you can tell what was checked for that subject.

If your list starts in Excel or CSV, map its columns to the supported JSON format first. Native .xlsx and CSV batch uploads are not supported. For larger files, use UTF-8 JSONL: one request per line, with no header or outer array. Batches use standard retention; minimal-retention rows are rejected.

The two subjects below are invented and use the synthetic sandbox package. Put one JSON object on each line for upload. For an inline batch, put the same objects in the subjects array. The reference field links a row to your records; it does not remove duplicate subjects for you.

Uploading a file does not start a screening job by itself. Save the upload ID, wait until the upload is validated and ready, then create the batch. Save the batch ID too. The job can keep running after you disconnect. The batch API guide explains each step and how to read every page of rows.

Consider four fictional suppliers. Two rows return no_match. One returns potential_match and needs review. The fourth fails because a required source is unavailable. That gives you three completed screenings and one failed check. It does not mean that all four suppliers have been approved.

A completed batch can still have failed rows. Read the row pages until nextOffset is null. Match each row back to the input and retrieve saved results by screening_id. Never turn a failed, pending, or cancelled row into a no-match in your own system.

Possible matches enter the same review queue as individual checks. Assign the case, compare each source record, and explain whether it is the same identity. Record the business decision separately and get a second review if required. A batch can finish while those cases remain open.

Correct unsuccessful subjects and submit them as a new job. Keep the first batch so your team can explain what happened to each row. If you cancel, pending work stops between chunks. Completed checks still count, and unused reservations are released. Repeating the whole file would create new checks for rows that already succeeded.

The batch row ledger helps you account for the input file. Use each completed screening ID to open its saved result or export its evidence. The screening register provides a CSV for a date range. It is not a dedicated batch-only download; use your saved row IDs to tie it back to a particular file.

A case packet gives you available facts and review history as PDF or JSON. Upload original PDFs, images, and passport scans directly to your organization’s document service, then link them to a case. SanctionsKit does not store those original files. Export while the case evidence still exists. See evidence exports and reports.

A file with 2,000 completed checks uses 2,000 screening units. If 200 failed rows are fixed and later finish, those checks add 200 units. Opening the earlier results or adding review decisions uses no extra units. A new check of the same subject does.

Add planned monitoring rescreens to the same monthly workload. Bulk files and uploads in progress also need enough file storage. Compare plans and example workloads before a large upload. A small synthetic sandbox file can help you test column mapping and error handling first.

Try a small file with made-up names. Include a row with a known error. Compare the number of names you sent with the results you got back. A batch can finish while some rows still need work. Keep those failed rows in view. Use the batch API reference to add bulk sanctions screening to your app.