Payment screening

Screen payments in milliseconds against sanctions and watchlists to rapidly detect and prevent suspicious or illicit activity.

SEON’s payment screening adds a crucial layer of protection by screening both the sender and the receiver of your customers against global screening lists in a single API call. This real-time check supports compliance with both international and regional sanctions, PEP, watchlist, criminal and adverse media sources, all before funds move.

Key benefits:

• Real-time screening: Detect and act on risky payments in milliseconds.
• Single API integration: All screening happens within the Fraud API request: All screening happens within the Fraud API request.
• Comprehensive coverage: Screen both sender and receiver, whether individuals or companies, all in one request with no extra steps.
• Fine-tuned control: Customize matching logic using fuzzy, phonetic and score-based thresholds.
• Fully Integrated: Manage results via SEON’s Scoring Engine, Alerts and Case Management UI.

Payment Screening is an API-first solution that requires integration with the Fraud API. However, the results can also be managed through SEON's Case Management and Scoring Engine within the admin UI.

• Payment processors, wallets, digital banks, remittance apps or others that need counterparty due diligence.
• Businesses in regulated sectors looking to cut manual work without compromising compliance.
• Companies seeking effective risk mitigation without introducing downstream friction or exposing the business to compliance penalties.

Enabling Payment Screening

To enable Payment Screening, include a new payment_screening object within the AML section of your Fraud API V2 request configuration. This object contains two configuration blocks:

• sender_config
• receiver_config

Each block allows you to define separate risk settings for the sender and receiver in a transaction.

Example request

{
  "config": {
    "aml": {
      "payment_screening": {
        "sender_config": {
          "type": "UNKNOWN",
          "sources": {
            "sanction_enabled": true,
            "pep_enabled": true,
            "watchlist_enabled": true,
            "crimelist_enabled": true,
            "adversemedia_enabled": true
          },
          "fuzzy_enabled": true,
          "fuzzy_config": {
            "phonetic_search_enabled": false,
            "edit_distance_enabled": true,
            "scoring": {
              "result_limit": 10,
              "score_threshold": 0.585,
              "adverse_media_scores": {
                "fuzziness": 0,
                "exact_match": true,
                "force_dob_filter": true,
                "force_country_filter": true
              }
            }
          }
        },
        "receiver_config": {
          "type": "UNKNOWN",
          "sources": {
            "sanction_enabled": true,
            "pep_enabled": true,
            "watchlist_enabled": true,
            "crimelist_enabled": true,
            "adversemedia_enabled": true
          },
          "fuzzy_enabled": true,
          "fuzzy_config": {
            "phonetic_search_enabled": false,
            "edit_distance_enabled": true,
            "scoring": {
              "result_limit": 10,
              "score_threshold": 0.585,
              "adverse_media_scores": {
                "fuzziness": 0,
                "exact_match": true,
                "force_dob_filter": true,
                "force_country_filter": true
              }
            }
          }
        }
      }
    },
    "response_fields": "aml_details"
  },
  "user_fullname": "Example Name",
  "user_firstname": "Example",
  "user_middlename": "",
  "user_lastname": "Name",
  "user_dob": "1990-01-01",
  "user_pob": "Budapest",
  "user_photoid_number": "56789",
  "user_id": "123456",
  "receiver_fullname": "string",
  "receiver_firstname": "string",
  "receiver_middlename": "string",
  "receiver_lastname": "string",
  "receiver_dob": "1980-01-01",
  "receiver_pob": "string",
  "receiver_photoid_number": "string",
  "receiver_id": "string",
  "receiver_country_iso": "string"
}

Customizing risk profiles

You can configure different fuzzy matching and data source preferences for both the sender and receiver. This flexibility allows compliance officers to tailor the risk screening strategy for each party in a transaction.

For instance, SEON customers may choose to apply a more thorough screening, such as enabling PEP and watchlist checks, for their own users, while applying a more targeted check (e.g., sanctions only) for the counterparty, depending on the associated risk level and desired objectives.

Learn more about the configuration options available in this integration guide.

To ensure the Payment Screening process runs correctly, please be aware of the following input validation rules:

• If a payment_screening object is included with a sender_config but no receiver_config, only the sender will be screened.
• If the payment_screening object includes a receiver_config but no sender_config, payment screening will be skipped entirely.
• If both sender_config and receiver_config are present and user_fullname is provided, but receiver_fullname is missing, only the sender will be screened.
• If the payment_screening object is present but user_fullname is not provided, payment screening will be ignored.

Once a sender or receiver match is detected, you can utilize SEON’s Scoring Engine to take immediate action or surface alerts for further review:

1. Automate actions with the Scoring Engine : Create Compare Rules in the Scoring Engine based on counterparty screening results. This enables automated decision-making, for example, you can automatically decline a transaction if the counterparty appears on a sanctions list or place the payment on hold pending further verification.
2. Generate alerts in Case Management: Configure alerts to trigger when a screening match occurs. You can then review, annotate and escalate cases as needed using SEON’s Case Management tools all while keeping a complete audit history.

Payment (outbound transaction)

In cases where funds are paid by a user, the beneficiary (the recipient of the transaction) should be added to the receiver_config. The nature of the transaction can be captured using the action_type field.

"aml": {
 "payment_screening": {
   "sender_config": {
     "type": "UNKNOWN",
     "sources": {
       "sanction_enabled": true,
       "pep_enabled": true,
       "watchlist_enabled": true,
       "crimelist_enabled": true,
       "adversemedia_enabled": true
     },
     "fuzzy_enabled": true,
     "fuzzy_config": {
       "phonetic_search_enabled": false,
       "edit_distance_enabled": true,
       "scoring": {
         "result_limit": 10,
         "score_threshold": 0.585,
         "adverse_media_scores": {
           "fuzziness": 0,
           "exact_match": true,
           "force_dob_filter": true,
           "force_country_filter": true
         }
       }
     }
   },
   "receiver_config": {
     "type": "UNKNOWN",
     "sources": {
       "sanction_enabled": true,
       "pep_enabled": true,
       "watchlist_enabled": true,
       "crimelist_enabled": true,
       "adversemedia_enabled": true
     },
     "fuzzy_enabled": true,
     "fuzzy_config": {
       "phonetic_search_enabled": false,
       "edit_distance_enabled": true,
       "scoring": {
         "result_limit": 10,
         "score_threshold": 0.585,
         "adverse_media_scores": {
           "fuzziness": 0,
           "exact_match": true,
           "force_dob_filter": true,
           "force_country_filter": true
         }
       }
     }
   }
 },
 "response_fields": "aml_details",
 "action_type": "outbound",
 "user_fullname": "Example Name",
 "user_firstname": "Example",
 "user_lastname": "Name",
 "user_dob": "1990-01-01",
 "user_pob": "Budapest",
 "user_photoid_number": "56789",
 "user_id": "123456",
 "receiver_fullname": "John Doe",
 "receiver_firstname": "John",
 "receiver_lastname": "Doe",
 "receiver_dob": "1980-01-01",
 "receiver_pob": "New York",
 "receiver_photoid_number": "123456789",
 "receiver_id": "987654",
 "receiver_country_iso": "US"
}

Bank transfer (inbound transaction)

In an inbound transaction, where the user is the beneficiary, the counterparty (payer) should be added to the receiver_config. The action_type should reflect the direction of funds, e.g., "action_type": "inbound".

"action_type": "inbound",
 "user_fullname": "Example Name",
 "user_firstname": "Example",
 "user_lastname": "Name",
 "user_dob": "1990-01-01",
 "user_pob": "Budapest",
 "user_photoid_number": "56789",
 "user_id": "123456",
 "receiver_fullname": "John Doe",
 "receiver_firstname": "John",
 "receiver_lastname": "Doe",
 "receiver_dob": "1980-01-01",
 "receiver_pob": "New York",
 "receiver_photoid_number": "123456789",
 "receiver_id": "987654",
 "receiver_country_iso": "US"

Purpose tagging (custom field)

In scenarios where transaction purpose matters (e.g., securities purchase), it can be specified in the custom_fields object.

"custom_fields": {
 "transaction_purpose": "securities_purchasing_order"
}

Adding custom metadata like this allows for enhanced auditability, monitoring and compliance reporting based on transaction context.

Input validation for payment screening

To ensure the payment screening process runs correctly, please be aware of the following input validation rules:

• If a payment_screening object is included with a sender_config but no receiver_config, only the sender will be screened.
• If the payment_screening object includes a receiver_config but no sender_config, payment screening will be skipped entirely.
• If both sender_config and receiver_config are present, and user_fullname is provided, but receiver_fullname is missing, only the sender will be screened.
• If the payment_screening object is present but user_fullname is not provided, payment screening will be ignored.

Once a sender or receiver match is detected, you can utilize SEON’s Scoring Engine to take immediate action or surface alerts for further review:

• Automate actions with the Scoring Engine 
  Create compare rules in the Scoring Engine based on counterparty screening results. This enables automated decision-making, for example, you can automatically decline a transaction if the counterparty appears on a sanctions list or place the payment on hold pending further verification.
• Generate alerts in case management
  Configure alerts to trigger when a screening match occurs. You can then review, annotate and escalate cases as needed using SEON’s case management tools all while keeping a complete audit history.