Sanction Screening

Availability and commercial scope

Sanction Screening appears as KYC → Sanction Screening at /app/kyc/sanction only when the active license includes the KYC Module and sanction Sub-module and the installed OneView version supports it. Execution also requires an active compatible Sanction Screening connection from Prembly or OpenSanctions.

Sanction Screening and PEP Screening are independent provider operations. OneView does not combine them into a single AML request. Licensing, configuring, or running one does not include or run the other. Confirm the client's separate commercial approval, provider pricing, and permitted use for each operation before production use. One Sanction Screening request uses OneView execution capacity and may incur the provider's sanction-screening charge even when the outcome is not a match or the request later fails.

A screening result is a decision-support signal, not a legal conclusion. The client remains responsible for its lawful basis, applicable lists and jurisdictions, screening policy, escalation criteria, and final action.

Configure a connection

A connector administrator needs vendors:read and vendors:manage.

1. Confirm License & Updates → License lists KYC → Sanction Screening. Select Refresh after an approved license change.
2. If the Sub-module is licensed but absent, check License & Updates → System updates and apply the approved release that supports it.
3. Open Operations → Vendor connections and choose the released Sanction Screening service from Prembly or OpenSanctions.
4. Choose a supported environment and complete only the friendly credential fields OneView displays.
5. Select Save and validate, then confirm the connection is active and preferred for Sanction Screening in that environment.

Create and manage the Sanction Screening connection separately from a PEP connection, even when the provider issues the same account credential. Saved configuration confirms the installed contract and protected credential storage; it does not prove provider authentication, account balance, network access, or that a live screening will succeed.

OpenSanctions hosted production

OpenSanctions provides the separate sanction-screening service for this Sub-module. It screens the provider's sanctions-related categories, including relevant linked records, without also running a PEP query.

The released v1 connection uses the hosted OpenSanctions production API only. Obtain a commercial OpenSanctions API key under the client's provider agreement, store the authoritative value in the client's secret manager, and enter it in the friendly OpenSanctions API key field. Confirm current pricing, usage allowances, processing terms, covered lists, and supported screening categories directly with OpenSanctions before production use.

There is no OpenSanctions sandbox connection in v1. Provider-approved synthetic tests use the hosted production service and may count toward provider usage or charges. Self-hosted or on-premises OpenSanctions yente is not a supported OneView v1 connection.

Run a browser screening

A browser user needs verifications:execute. verifications:read provides metadata-only history, while verifications:results:read is additionally required to reveal stored result previews and details.

1. Open KYC → Sanction Screening.
2. Select New Verification and choose an active Sanction Screening connection.
3. Enter First name and Last name.
4. Add the optional friendly fields supported by the selected service only when approved and available. OpenSanctions displays Middle name, Date of birth, Nationality, and Gender. Do not invent an optional value to make the request appear more complete.
5. Optionally enter a safe operational purpose that contains no name or other identity data.
6. Review the selected operation and subject fields, then select Run verification once.

Sanction Screening does not run PEP Screening in the background. Run the other Sub-module separately only when the client's approved process requires it. After an uncertain outcome, review history before trying again to avoid a duplicate provider charge.

OneView does not automatically retry an OpenSanctions Sanction Screening provider call. If the browser disconnects or the request outcome is uncertain, review verification history before submitting again and reconcile provider usage when required.

Synchronous API

An external client application uses an active API Service Account and the released endpoint. The selected connection determines the provider contract:

This example selects a hosted OpenSanctions production connection:

POST /api/verifications/sanction
Authorization: Bearer <service-account-api-key>
Idempotency-Key: sanction-screen:00000001
Content-Type: application/json

{
  "connectionId": "<active-opensanctions-sanction-connection-id>",
  "purpose": "Approved customer screening",
  "data": {
    "firstName": "<provider-approved-synthetic-first-name>",
    "lastName": "<provider-approved-synthetic-last-name>",
    "middleName": "<optional-synthetic-middle-name>",
    "dateOfBirth": "<optional-supported-value>",
    "nationality": "<optional-supported-value>",
    "gender": "<optional-supported-value>"
  }
}

data.firstName and data.lastName are required for both providers. Use only the optional fields supported by the selected connection. Follow the friendly labels and exact date, nationality, and gender formats shown by that connection's API Usage panel. Omit an unavailable optional field instead of sending an empty or invented value. Omit connectionId only when the preferred active production Sanction Screening connection is intended.

The response follows the common Synchronous API envelope. A completed normalized result includes the screening outcome, whether a match was indicated, the match count, the searched name, provider-specific guidance, and whether manual review is required.

Prembly nested sanction-match details are not available in v1 because a stable provider match-detail schema has not been published for that service. OpenSanctions exposes only bounded normalized screening fields, not its raw response or a complete provider profile. Its match confidence describes how strongly the submitted identity resembles a candidate. It is not a risk rating, proof of sanctions status, or a client decision. Do not build client decisions around undocumented provider fields.

Interpret the result

The normalized outcome has one of these values:

• clear — no candidate match was identified from the completed screening; this is not a permanent guarantee or a statement about lists outside the approved service.
• potential_match — one or more candidates require manual comparison and client review.
• match — the service identified a strong match signal; the client must still follow its approved review and decision process.
• inconclusive — OneView cannot present a confident screening conclusion; do not treat it as clear.

matched is the normalized match indicator, and matchCount is the number of candidate matches represented by the normalized result. searchedName records the normalized search name. Provider-specific risk guidance, OpenSanctions match confidence, and the manual-review indicator guide the next step; they do not make a legal, onboarding, employment, payment, or account decision for the client.

For potential_match, match, or inconclusive, route the case to an authorised reviewer. Use only the bounded normalized fields available for the selected service and follow the client's approved provider-review and escalation process for any additional evidence needed to resolve the case. Do not treat the absence of a raw or nested provider record as proof that there was no match.

Troubleshooting and safe handling

• Sanction Screening is missing — confirm the sanction entitlement, refresh the license, confirm the installed version, and sign in again. A PEP entitlement does not grant Sanction Screening.
• No connection is available — confirm a released Sanction Screening service connection is active in the intended environment and preferred when the request omits connectionId.
• Input is rejected — provide both names and use only the optional gender values displayed by the selected service.
• Provider request fails — confirm the Sanction Screening connection, provider account state, network allow-listing, and safe error code. Reconcile uncertain requests before retrying.
• Prembly has no nested match details — this is its supported v1 result boundary. Use the approved manual-review process; do not seek raw provider fields in logs or support bundles.
• OpenSanctions is unavailable in sandbox — use its hosted production connection with a client-approved synthetic test and confirm possible provider usage or charges first. Do not configure a self-hosted yente endpoint.
• OpenSanctions rejects the credential — re-enter the client's complete commercial API key from its secret manager and confirm the provider account is active. Do not paste the key into logs or support requests.
• Confidence looks high — treat it as match confidence, not subject risk or a final sanctions finding. Complete the approved manual review.
• Result is unexpected — confirm the request used Sanction Screening rather than PEP Screening. Do not repeatedly resubmit a real person to seek a different answer.

Names and screening results are personal data. Never place them in URLs, idempotency keys, logs, metrics, screenshots, chat, or support tickets. When an OpenSanctions connection is selected, the approved identity fields are sent to the configured OpenSanctions hosted production API. Include that transfer in the client's privacy review and data map. Use provider-approved synthetic identities for testing.