Transaction Screening

In order to ensure you do not ship to a restricted or denied party, you should screen the parties on your transactions against the restricted party lists.

The screening process executes the following steps on your transaction:

1. Screening service gets the service preference as an input.
2. All the parties on the trade transaction/declaration as well as the corresponding lines are retrieved.
3. Screening is performed on any party not screened previously. You can avoid screening of any party on trade transaction/declaration by excluding it using gtm.rps.involved_party_qual.exclude property. For example, you may want to exclude screening of all your SHIP_FROM involved parties since all the facilities you ship from are company owned. Since all the facilities are internal, you can bypass screening for them.
4. Next, the RPLS status of trade transaction/declaration line is set to:
   • TL_RPLS_FAILED if there is even one party with the RPLS_FAILED status.
   • TL_RPLS_REQUIRES REVIEW if there is no party with the RPLS_FAILED status but at least one party with RPLS_REQUIRES REVIEW status.
   • TL_RPLS_PASSED if none of the parties have the RPLS_REQUIRES REVIEW or RPLS_FAILED status.
5. Then, the RPLS status of trade transaction/declaration is set to:
   • TS_RPLS_FAILED if there is even one trade transaction/declaration line with the RPLS_FAILED status.
   • TS_RPLS_REQUIRES REVIEW if there is no trade transaction/declaration line with the RPLS_FAILED status but at least one trade transaction/declaration line with RPLS_REQUIRES REVIEW status.
   • TS_RPLS_PASSED if none of the trade transaction/declaration lines have the RPLS_REQUIRES REVIEW or RPLS_FAILED status.

   Note: The shipment execution is stopped for any transaction with an RPLS_FAILED status.

It is recommended to:

• If there is a change in any of the restricted party screening properties, you should trigger complete rescreening.
• When there are a large number of parties to be screened, you can scale up by increasing the threads on the event groups 'agentGtmRPLS' for party screening and 'agentGtmCompliance' for trade transaction screening.
• When there are a large number of parties to be screened, you can scale up using the scalability capability. By using scalability, you can route the restricted party screening request to a dedicated application instance.
• You can increase the WebLogic TLA parameter to help when maximum number of threads are in use and are struggling for resources.