Compliance can be activated in the static data transaction Maintaining System Configuration, the combobox “Compliance” allows the following options:

• Compliance Active (this option is using the built-in 'old' compliance functionality)
• Alternative Compliance Active (this option is interacting with an external Sanction-Screening-System, such as WOLF)

The main principle of both compliance modes is the same. The key differences between 'old' and 'alternative' modes are shown in the table:

Activation of the “Alternative Compliance” enables compliance checking of

• Business transactions
• Party static data
• Incoming messages.

In the static data transaction Maintaining System Configuration, it is possible to deactivate the compliance checking of a certain type, such as for incoming messages.

The data that is checked is mainly data defined in textfields, eg address blocks of parties, large narrative fields such as the 'goods description' field in the L/C. The ini file dngcpl.ini holds the list of fields that are checked. Additional fields can be defined in the 'Compliance' panel in Maintaining System Configuration.

The fields “Compliance Check” in the transaction Maintaining Entity Group Transaction Profiles allow per business transaction if and how the transaction is executing compliance checking:

• None
• Always
• Only if transaction sends a message

The field “Compliance Priority” can be set to “Normal” or “Urgent”. The priority is intended for an external compliance system and will be included in the output XML in the header tag “<MessagePriority>”.

Additional fields + contract roles for screening can be added on the compliance panel. Roles that should be skipped from compliance checking can be provided in the fields “Contract Roles” and “Roles in payment messages”.

The magnifier glass next to the list shows which fields are filled by default into the compliance message. It displays the fields from all business sectors, fields used in settlement grid and fields used in message grid. These fields are defined in DNGCPL.INI. However, this init file can be changed using Maintaining System Configuration (i.e. fields can be added/deleted for compliance definition).

• Transaction Opening an Import L/C is processed to issue a Letter of Credit. The business transaction is set in Maintaining Entity Group Transaction Profiles to 'only if the transaction sends a message'.
• When the transaction Opening an Import L/C is saved, the transaction has to pass the workflow via the Task Manager (MGRTSK).
• The Compliance service “CCS” will execute the compliance check before the services PDS for pending signature, PDP for Pending predecessor transactions and COM (Commit) are executed.
• Running the service CCS creates an XML file in the defined directory (e.g ..data\ccsout).
• The data in the XML file will then be checked by the sanction screening system and that will update DOKA-NG whether a hit was found.
• The received reply from the sanction screening system is handled similar to an incoming message.
• The reply/acknowledgment from the sanction screening system will appear in DOKA-NG in data\ccsin\folder. If manual processing of an acknowledgement for testing or demo purpose is needed, the file Readme.txt contains instructions on how to do this.

When a hit is found by the compliance system, the transaction is sent to the correction queue and an infotext to the user is created.

The user can manually overwrite the positive hit of the compliance system using the checkbox “Compliance False Positive accepted” on the “Compliance” panel of the business transaction. Further explanatory comments can be added into the associated textfield. Doing so will turn off the compliance checking for the particular transaction and create a warning to the releaser.

To be able to have party/ address changes in the static data transactions checked by compliance, it is necessary to have the 4 Eye Principle activated for the party static data table PTY in Maintaining System Configuration.

If the party in the static data transaction Maintaining Parties is flagged as a “Sanctioned Party”, then all changes have to pass the compliance check.

After saving the change in DBEPTY, the static data entry is waiting for the release and also for compliance checking by service “CCS” in the Task Manager.

Incoming messages are imported into the application with the Manager for Incoming Messages and have to pass the compliance check before becoming available for processing.

The incoming SPT is blocked for further processing in status “Waiting for Compliance” until the service “CCS” in the Task Manager is completed successfully.