Lesson 2 of 6
Sanctioned-party screening
10 min
Listen to this lesson
Sanctioned party list (SPL) screening checks names and addresses of business partners, and of the partners on documents, against government lists of restricted parties. In the US these include, for example, the Treasury Department's OFAC Specially Designated Nationals list and the Commerce Department's Entity List and Denied Persons List. Companies normally buy consolidated lists from a data provider who delivers updates in an XML format GTS can upload.
The moving parts
| Element | What it does | Where in GTS E4H |
|---|---|---|
| SPL master data | The list entries: names, addresses, list type, validity | Uploaded by the administrator; viewed and maintained in Manage SPL List |
| Business partners | Customers, suppliers and other partners replicated from the feeder | Manage Business Partner |
| Comparison terms or HANA search | How names are matched: GTS comparison terms or SAP HANA search, set in the legal regulation | Customizing and administration |
| Screening of partners | Periodic and delta screening of new and changed partners | Background jobs; results in Manage Business Partners – SPL Screening |
| Screening of documents | Partners on orders, deliveries and POs checked when the document arrives | Blocked documents in Manage Blocked Documents |
| Audit trail | Record of every screening, match and decision | SPL audit trail |
SPL elements and where they live, from SAP's user guide for release 2025.
Two behaviors from SAP's documentation matter for testing. First, a business partner released manually is not blocked again at the next periodic screening as long as nothing relevant changed; a change to the partner's address, to the SPL data or to Customizing triggers a fresh screening. Second, you cannot release a partner that appears on an official list as a true match; release is for false positives.
Worked example: a false positive
A new Canadian aftermarket distributor is created in CMP as business partner 17100245 (illustrative), named "Northgate Auto Electric Ltd." The delta screening job matches it against a list entry with a similar name in another country. GTS blocks the partner and every sales order for it. Ingrid opens the hit, compares name, address, country and identifiers, finds the entry refers to a different company in a different country, and releases the partner with a documented reason. The audit trail records who decided, when and why. Two months later the distributor changes its address; the next screening ignores the old release and screens again.
Step by step: testing screening
- Agree with Ingrid a set of test parties: one exact match to a list entry, one near match (spelling variation), one false positive, one clean partner, and one released partner whose address will change.
- Load the test parties in CMQ as business partners in the feeder; never invent names that resemble real sanctioned persons outside the test system.
- Run the delta screening job and check the result per partner in Manage Business Partners – SPL Screening.
- Create a sales order for each partner; confirm blocked and unblocked orders in the feeder and in Manage Blocked Documents.
- Release the false positive with a reason; change its address and rerun screening; confirm it is screened again.
- Export the audit trail entries for all test parties as evidence.
| Test party | Expected result | Evidence |
|---|---|---|
| Exact match | Blocked; release not possible as a true match | Screening result, blocked order, audit entry |
| Near match (spelling) | Blocked as possible match | Hit details showing the similarity |
| False positive | Blocked, then released with reason | Release entry with user, time, reason |
| Clean partner | Not blocked | Screening result without hit |
| Released, then address changed | Screened again, decision not reused | Second screening entry |
Operating screening day to day
Screening is a daily operation, not a one-time setup. The data provider publishes list updates often, sometimes several times a week when sanctions change quickly. Contoso's runbook: the administrator uploads each new list version, checks the upload log for a green status, and the delta screening job then rescreens all partners against the changed entries overnight. Ingrid's team works the resulting hits each morning before the first trucks are loaded. The periodic full screening runs monthly.
| Job or task | Frequency | Owner | Check |
|---|---|---|---|
| SPL list upload | Each provider update | GTS administrator | Upload log status and date |
| Delta screening of new and changed partners | Nightly | Job scheduling | Job log; count of partners screened |
| Full periodic screening | Monthly | Job scheduling | Job log; hits reviewed |
| Hit review | Each morning | Ingrid's team | No hit older than one working day |
Contoso's screening operations (illustrative course data).
What would you do?
Sales asks Ingrid to release a blocked Mexican customer quickly because a large order is waiting. The hit shows the same name, city and tax ID as an entry on an official list. What is the right response?
- SPL lists come from a data provider as XML and are uploaded by the administrator.
- Partners are screened periodically and on change; documents are screened on arrival.
- Releases are for false positives and hold only while the underlying data is unchanged.
- Test with prepared parties and check that the list itself is current.
Check your understanding · not graded
Lesson check
1. Which app shows and maintains SPL entries in GTS E4H?
2. When is a manually released partner screened again?
3. Can a partner that truly matches an official list be released?
4. Which risk do functional SPL tests often miss?