Bright Sea field guide · Version 1.1

Control Evidence Map

A practical framework for translating a sanctions-screening policy into an owned, testable, and evidence-producing operating control.

Download the Word field guide

Artifact ID: BS-CEM-001

Status: Illustrative resource

Review cycle: December 2026 and upon material regulatory change

How to use it

Map the whole control before choosing the tool

Start with the obligation and desired outcome. Work through each stage until a reviewer can identify what runs, who decides, what happens when the process fails, and what record proves the result.

Software may perform part of the workflow. The control also depends on scope, data quality, configured rules, holds, escalation, authority, evidence, quality review, and independent testing.

For the reasoning behind each field, read How to Turn a Sanctions Policy Into an Operating Control.

Bright Sea working standard: a control is ready for operation when an accountable person can run it, reconstruct it, test it, and correct it.

The map

Seven connected decisions

A gap in any stage weakens the operating control or the evidence available to defend it.

  1. Step 01 of 7:

    Obligation

    What requirement or risk is the control addressing?

    Applicable authority, policy statement, contractual requirement, and risk statement.

  2. Step 02 of 7:

    Control objective

    What outcome must the control produce?

    A specific, observable result tied to the obligation and the organization’s risk assessment.

  3. Step 03 of 7:

    Trigger and scope

    When does the control run, and which activity does it cover?

    Events, parties, products, jurisdictions, data fields, frequency, and exclusions.

  4. Step 04 of 7:

    Decision logic

    How does the control reach and route a result?

    Rules, configurations, thresholds, holds, queues, escalation criteria, and approval authority.

  5. Step 05 of 7:

    Exception path

    What happens when the normal process cannot finish?

    Outages, incomplete data, potential matches, overrides, time limits, and escalation paths.

  6. Step 06 of 7:

    Evidence

    What proves the control ran and the decision was authorized?

    Inputs, versions, timestamps, results, rationale, approvals, release events, and audit history.

  7. Step 07 of 7:

    Assurance

    Who owns, reviews, tests, and corrects the control?

    Operating owner, compliance owner, quality review, independent testing, metrics, and remediation.

Worked example

Pre-release sanctions screening

This synthetic example shows the level of definition required to make a policy statement operational. It does not determine whether any particular transaction is permitted.

Control ID
SAN-TRX-001
Control objective
Prevent release of an in-scope payment until required sanctions screening is completed and any potential match is resolved by authorized personnel.
Scope
Illustrative USD payment flow. Screen the sender, beneficiary, relevant financial institutions, and other parties or data identified by the organization’s risk assessment and applicable sanctions requirements.
Triggers
Before payment release; when relevant party data changes; when a list update or risk event requires rescreening; and after a screening outage is resolved.
Inputs
Names and aliases, addresses, country information, dates of birth or incorporation when available, identifiers, ownership and control information, bank data, intermediaries, payment narrative, relevant activity or jurisdiction restrictions, and license or exemption evidence when applicable.
Data-field mapping
Maintain a versioned map from every required input to its source system and the field sent in the screening request. Missing or truncated required data creates an exception.
Ownership review
Review ownership information against OFAC’s 50 Percent Rule because name screening alone will miss an unlisted entity blocked through aggregate ownership.
Decision logic
A completed screen with no unresolved alert may move to the next controlled step only when no other applicable ownership, jurisdiction, activity, license, exemption, or sanctions review prevents processing. A potential match creates a hold and case. Release requires documented resolution and the approval required by the control design.
System enforcement
The payments platform enforces the hold. Release remains unavailable while the case is open. Any attempted release during a hold is blocked and logged.
Exception paths
Incomplete data, unavailable screening service, stale list data, potential match, confirmed match, prohibited destination, and attempted manual override.
Operating owner
Payments Operations confirms screening completion and prevents release while an alert or required review remains open.
Compliance owner
Sanctions Compliance owns risk interpretation, rule requirements, escalation standards, and disposition authority defined by policy.
Responsible entity and partner allocation
Identify the legal entity that possesses or controls the funds, the party with each sanctions obligation, and the authority divided among the fintech, sponsor bank, payments partners, and service providers.
Disposition handoff
A block, rejection, unblocking, or authorized transaction routes to any required reporting, blocked-property administration, recordkeeping, licensing, customer-communication, or follow-up control, with a named owner and due date.
Quality and testing
Quality review samples completed cases and dispositions. Independent testing evaluates design and operating effectiveness using qualified personnel who are not involved in the function being tested.
Evidence and retention
Retain the evidence package for at least 10 years after the transaction, and retain blocked-property records for the blocking period plus at least 10 years after unblocking.

Illustrative record

One alert, reconstructed

Synthetic values demonstrate the chain of evidence without describing any client, transaction, or legal conclusion.

Record
DEMO-SAN-2026-001
Event
Illustrative USD payment to a new beneficiary. The payment entered a pre-release hold.
Screening result
Potential beneficiary-name match. The system created a case and prevented release pending review.
Analyst recommendation
Potential name match not confirmed after documented comparison of sufficient, reliable distinguishing information. If the available information had been insufficient, the payment would have remained held and moved to escalation. The analyst routed the recommendation and supporting record to the authorized approver.
Final disposition
Authorized reviewer approved case closure under the screening control. Separate checks addressed other applicable ownership, jurisdiction, activity, license, and exemption questions before release. The release event recorded the approver, timestamp, case identifier, final status, and any required downstream control handoff.

Evidence package

What the record should preserve

  • Screening request and protected source data record
  • Lists, programs, vendor configuration, and rule versions used
  • Request and response timestamps
  • Raw screening result and match information
  • Case creation, hold, and queue history
  • Analyst recommendation and supporting comparison
  • Authorized final disposition
  • Payment release, rejection, blocking, or escalation event
  • Required regulatory report, submission evidence, deadline, blocked-property record, and retention-control handoff when applicable
  • Quality-review result and any corrective action
  • Immutable or otherwise controlled audit history

Assurance

How to test the control

Run every failure-path and detection test in an isolated production-equivalent environment that uses a controlled replica or snapshot of the production configuration and synthetic data incapable of generating a live block, rejection, report, customer effect, or external transmission.

  1. Procedure 1 of 16: Sample released payments and confirm screening completed before release with the expected configuration in effect.
  2. Procedure 2 of 16: Sample alerts and reconstruct the evidence supporting each disposition.
  3. Procedure 3 of 16: Attempt release while an alert is unresolved and confirm the system prevents it.
  4. Procedure 4 of 16: Submit a payment with a required field missing or truncated and confirm the payment remains held.
  5. Procedure 5 of 16: Interrupt the screening service in a production-equivalent test environment, restore it, and confirm rescreening before release.
  6. Procedure 6 of 16: Build and clear a simulated alert backlog and confirm that no payment is released without review.
  7. Procedure 7 of 16: Change customer data, load a list update, and confirm rescreening.
  8. Procedure 8 of 16: Attempt a manual override with each user role and confirm restrictions, logging, review, and reporting.
  9. Procedure 9 of 16: Trace each required input from its source system to the screening request.
  10. Procedure 10 of 16: Run a detection test set with realistic name and identifier variations, including weak aliases where the program has chosen to screen them.
  11. Procedure 11 of 16: Onboard a test entity whose blocked owners hold 50 percent or more in the aggregate and confirm ownership review identifies it.
  12. Procedure 12 of 16: Trace configuration and threshold changes through approval, detection testing, deployment, and effective dates.
  13. Procedure 13 of 16: Retrieve a complete evidence package for an older transaction from the archive.
  14. Procedure 14 of 16: Confirm quality review is performed separately from initial disposition.
  15. Procedure 15 of 16: Confirm independent testing is performed by qualified personnel independent of the function under review.
  16. Procedure 16 of 16: For block, reject, unblock, or licensed outcomes, verify required reporting and follow-up handoffs were timely and evidenced.

Reusable framework

Blank control evidence map

Complete every field and identify unsupported assumptions before the control is approved for implementation.

Control ID and version

Control owner

Last reviewed date

01

Applicable authority and policy

02

Risk statement

03

Responsible legal entity, possession or control of funds, and fintech, sponsor-bank, partner, and provider allocation

04

Observable control outcome

05

Products, channels, parties, and jurisdictions in scope

06

Trigger events and frequency

07

Required data, source systems, and field mapping

08

Approved exclusions, rationale, and approver

09

Lists, rules, thresholds, and configuration owner

10

Normal workflow and system enforcement of holds

11

Decision authority and approval requirements

12

Post-disposition reporting, blocked-property, recordkeeping, licensing, communication, and follow-up handoffs

13

Outage, incomplete-data, backlog, and escalation paths with time limits

14

Override rules and permitted roles

15

Evidence produced and system of record for each element

16

Retention period, governing authority, and retrieval method

17

Operating owner and backup owner

18

Quality-review method and sample

19

Detection-testing method and frequency

20

Independent-testing method and frequency

21

Management metrics and escalation thresholds

22

Change-control requirements

23

Known limitations, unsupported assumptions, and accepted residual risk

Primary sources

Basis for the framework

OFAC administers sanctions programs. The FFIEC material supplies a bank examination and independent-testing lens. OFAC requirements are distinct from the Bank Secrecy Act.

Test the surrounding program

Use Bright Sea’s Diligence Question Set to examine the ownership, evidence, systems, capacity, and escalation structure surrounding the control.

Open the Diligence Question Set