OFAC SDN Screening Verification Log
Log each OFAC SDN screening for buyers and third-party payment sources, capture the match outcome, and retain clearance evidence in the deal jacket.
Trusted by frontline teams 15 years of frontline software AI customization in seconds
Built for: Financial Services · Real Estate · B2b Saas · Import/export · Professional Services
Overview
This OFAC SDN Screening Verification Log template captures the facts needed to show that a buyer or third-party payment source was screened, what was found, and who cleared the result. It is built around the screening record, the party screened, the screening result, evidence retention, and reviewer attestation, so teams can keep one consistent record instead of scattered emails or chat messages.
Use it when a transaction, onboarding step, or payment setup requires sanctions screening and you need a traceable record for the deal jacket. The template is especially useful when multiple people touch the process, when a potential match needs review, or when you must show that evidence was retained with the file. It also supports progressive disclosure: if there is no match, the log stays simple; if there is a potential match, the match details and review fields become the focus.
Do not use this as a substitute for your sanctions policy, legal review, or screening system. It is not meant for broad customer profiling, and it should not collect extra PII that you do not need to document the check. If your workflow only needs a simple pass/fail record, keep the identifier fields narrow and use the supporting files section for the actual evidence. The goal is a clean audit trail that is easy to complete, easy to review, and easy to retrieve later.
Standards & compliance context
- This log supports an audit trail for sanctions screening, but the final clearance decision should follow your internal OFAC review process and any required legal escalation.
- Apply GDPR data minimization by collecting only the identifiers needed to distinguish the screened party and by avoiding unnecessary PII in match notes.
- If the form is used in a public-facing or shared workflow, make the fields accessible under WCAG 2.1 AA with clear labels, keyboard navigation, and visible required markers.
- Use anonymous submission only if your policy allows it and the workflow does not require named attestation or reviewer accountability.
- Retain supporting files in a controlled location with access limits so the deal jacket reference points to evidence that can be audited later.
General regulatory context for orientation only — verify current requirements with counsel or the relevant agency before relying on this template for compliance.
What's inside this template
Screening Record
This section captures when the screening happened, why it was run, and who performed it so the audit trail starts with the right context.
-
Screening Date
Date the OFAC SDN screening was completed.
-
Screening Time
Optional time of screening for audit trail reference.
-
Reason for Screening
Select the business event that triggered the screening.
-
Screening Performed By
Name or team identifier of the person completing the screening.
Party Screened
This section identifies the exact party checked and keeps the data narrow enough to support screening without collecting unnecessary PII.
-
Party Type
Choose whether the screening applies to the buyer or a third-party payment source.
-
Legal Name
Legal name used for sanctions screening. Avoid collecting extra PII unless needed.
-
Country or Region
Optional jurisdictional context if relevant to the screening process.
-
Identifier Type
Use only if your compliance process requires an additional identifier.
-
Identifier Value
Enter the selected identifier value only when needed for screening.
Screening Results
This section records the outcome, any match details, and the final clearance decision so reviewers can see how the case was resolved.
-
Screening Result
Select the result of the OFAC SDN screening.
-
Match Details
Summarize the basis for the hit, the data reviewed, and any distinguishing factors used to assess the result.
-
Clearance Status
Select the disposition for any hit or potential hit.
-
Clearance Decision Date
Date the clearance or escalation decision was made.
Evidence and Retention
This section ties the screening to retained proof and a deal jacket reference so the supporting files are easy to locate later.
-
Evidence Retained in Deal Jacket
Select all evidence items retained to support the screening outcome.
-
Deal Jacket Reference
Reference number, folder path, or document ID where the evidence is stored.
-
Supporting Files
Upload supporting evidence if your process allows file retention in the form.
Review and Attestation
This section shows whether a second review was required and who attested to the decision, which is critical when a potential match needs escalation.
-
Compliance Review Required
Check if the screening result requires additional compliance review.
-
Reviewer Name
Name of the compliance reviewer when escalation is needed.
-
Attestation
Required acknowledgement for the person submitting the log.
How to use this template
- 1. Enter the screening date, time, reason, and the person who performed the check so the log shows when and why the screening happened.
- 2. Record the party type, party name, country or region, and the minimum identifier needed to distinguish the party without collecting unnecessary PII.
- 3. Select the screening result, add match details only when needed, and set the clearance status and decision date based on the actual review outcome.
- 4. Attach or reference the supporting evidence, then point the deal jacket reference to the exact file, folder, or record location used for retention.
- 5. Route the record to a reviewer when required, capture the reviewer name, and complete the attestation only after the clearance decision is confirmed.
Best practices
- Use a date picker and time field for the screening record instead of free text so the audit trail stays consistent.
- Mark only the fields you truly need as required and keep identifier collection to the minimum necessary for the screening decision.
- Use conditional logic to reveal match details and reviewer fields only when the screening result requires escalation.
- Record the exact party type, such as buyer, beneficial owner, or third-party payment source, so reviewers know what was screened.
- Store the evidence_retained flag together with a precise deal jacket reference so the supporting file can be found without searching email threads.
- Capture the clearance decision date as soon as the review is complete to avoid gaps between screening and approval.
- If a potential match is unresolved, document the interim status clearly rather than forcing a pass or fail decision.
What this template typically catches
Issues teams running this template most often surface in practice:
Common use cases
Frequently asked questions
What is this log used for?
This template records each OFAC SDN screening event, the party screened, the result, and the evidence retained. It is meant to create a clear audit trail for buyer and third-party payment source checks. Use it when you need a repeatable record of who was screened, when, and how the clearance decision was made.
Who should complete the screening record?
The person actually performing the screening should complete the screening date, time, reason, and their name. In many organizations this is a compliance, finance, operations, or deal desk reviewer. If screening is delegated, the log should still show the individual who ran the check and the reviewer who approved the outcome.
How often should this log be used?
Use it every time a buyer or third-party payment source is screened, not just at onboarding. Many teams also rerun screening when a deal changes, a party name is updated, or a new payment source is introduced. The log works best when it captures each discrete screening event rather than a single one-time record.
What counts as a match or potential match?
A match is any screening result that requires review because the name, identifier, country or region, or other details resemble a restricted party record. The match details field should capture enough context to explain why the result was escalated or cleared. If the result is inconclusive, the log should show the decision path and who resolved it.
Does this template replace legal or sanctions review?
No. It is a documentation log, not a legal determination tool. It helps teams record the screening process, retain evidence, and show who reviewed the outcome, but sanctions decisions should still follow your internal compliance policy and any required legal review. If your process requires escalation, the review and attestation section should reflect that.
What evidence should be retained with the log?
Retain the screening output, clearance notes, supporting files, and any documents that explain the decision, such as entity details or correspondence used to resolve a potential match. The deal jacket reference should point to the exact file location or record ID so the evidence can be found later. Avoid storing unnecessary PII beyond what you need to document the screening.
Can this be customized for different deal types or systems?
Yes. You can add fields for deal ID, customer account number, screening tool name, or escalation status if those are part of your workflow. The template also works well with conditional logic, such as showing reviewer fields only when the result is not automatically cleared. Keep the form aligned to data minimization so you only collect what you actually use.
How does this compare with ad-hoc email approvals?
Ad-hoc email approvals are hard to search, easy to lose, and often leave gaps in the audit trail. This log standardizes the screening record, makes required versus optional fields clear, and ties the result to retained evidence. It is easier to review during internal audits because the key facts are captured in one place.
Related templates
Go deeper on the topic
-
Lockout/tagout (LOTO) is the procedure for controlling hazardous energy — electrical, hydraulic, pneumatic, mechanical, thermal, chemical — before...
-
Job hazard analysis (JHA) — also called job safety analysis (JSA) — is the structured exercise of breaking a work task into sequential steps, identifying the...
-
A near-miss is an event that could have caused injury or damage but didn't — a slip that didn't fall, a load that shifted but didn't drop, a machine that...
-
AI governance is the framework a company uses to decide what AI tools are allowed to do, who's accountable for their outputs, what data they're allowed to...
-
Manual HR data entry costs $4.78 per entry and introduces bias into pay decisions. Learn how automating performance data creates fairer, more accurate...
-
See how the Kansas City Chiefs unified communication for 600+ event staff with a branded app, achieving 90% adoption and reaching every employee on game day.
-
Discover how continuous feedback, dynamic goal-setting, and psychological safety replace annual review dread with a no-surprise performance culture that...
-
MangoApps 2026 Winter Release adds native shift scheduling, structural AI for surveys and wikis, and a redesigned search—unifying frontline operations in one...
Ready to use this template?
Get started with MangoApps and use OFAC SDN Screening Verification Log with your team — pricing built for small business.
