Single Transaction Check 

Use

The term single transaction check (STC) refers to all check activities relating to the relevant limits that can be applied to a single trading or credit transaction when you enter or edit it. You can trigger the single transaction check in the following ways:

·        In the application menu (STC transaction)

·        By using an RFC module

·        By using the integrated default risk limit check (the integrated default risk limit check is available in SAP Treasury and Risk Management only)

The relevant attributable amounts are determined for the data supplied and for all the risk categories that are released for a single transaction check. The system checks the maximum risk commitment period that was defined, the internal and external limits, and the critical limit utilization.

The single transaction check is a tool you can use for up-to-date risk monitoring. This is controlled by determination procedures.

Depending on the settings in Customizing, you can activate 24-hour capability for the single transaction check. This means that you can trigger the single transaction check at any time, even when end-of-day processing is running.

Prerequisites

When you define the limit type, you need to enter Update category 2 if you want the system to determine the current limit usage for the individual limits. The update category of a limit type specifies whether limit utilization is updated during the day. In Customizing choose... ® Limit Management ® Define Limit Types.

You also need an STC product, which you define in Customizing. In Customizing choose...® Basic Settings ® Definitions ®  Define Single Transaction Check Product.

The results of the single transaction check are valid only if the utilization of the limits was calculated in an end-of-day processing run, the key date of which is in the past. The limits referred to here are the ones affected by the limit characteristics of the transaction that is to be checked.

To be able to use all the functions of the single transaction check, authorization profile F_T_FTLM_ALL with authorization object J_B_KLSDC1 must be stored in your user master record. Depending on the extent of your authorization, you can obtain further information by branching from the functions of the STC.

Features

You have the following options for triggering the single transaction check:

·        Manually in the application menu

Your options include

¡        Checking new transactions

¡        Checking existing transactions

¡        Deactivating external transactions

¡        Displaying an overview of transactions

 

·        Automatically by using the RFC module KL_EXT_CALCULATE_AROBJ_RFC

Using this interface you can create a direct connection between the bank’s own front-end system and the limit system. Refer to the technical documentation on the function module in the ABAP Workbench.

When you enter or edit transactions in an external system (upstream with regard to Limit Management), the single transaction check involves the following steps:

...

       1.      Call-up of the interface for the single transaction check

       2.      Determination of the limits relevant for the single transaction check

       3.      Calculation of the attributable amounts of the transaction

       4.      Calculation of the current limit utilizations of the limits relevant for the check

       5.      Check for compliance with the limits

       6.      Reporting of the results of the check to the user processing the transaction

       7.      Generation of a log of the results of the check for the documentation in Limit Management

       8.      Updating of limit utilizations

In addition to updating limit utilizations, you have the option of just checking a transaction. During the check, the system determines an attributable amount. This is checked against the limits, and the result is reported back to the user. The limit utilization is not updated.

Integration

All transactions that are created in the SAP system by means of the single transaction check are initially recognized by the system only as external transactions. For the check made in end-of-day processing, the transaction data can still be transferred from the operational system to the SEM data pool (by means of external data transfer or online maintenance). During the next end-of-day processing run, using the transaction key the system compares the external transactions and the new SAP-internal transactions to avoid duplicating any data. If no data pool transaction exists, the external transaction remains in Limit Management even after the end-of-day processing run.

Activities

During the single transaction check, the system checks the transactions without accessing any transaction information that might exist in the data pool. This means that the system needs to be provided with all limit-relevant data. You have to supply the following data:

Indicator for simulation	Indicator showing whether a simulated (check) or valid (save) transaction is involved.
External administration key	This identifies the transaction.
Limit characteristics
Base date of the fictitious transaction	This date is the value date from which there is a potential settlement risk.
Base date for the calculation of the market value change period
Base date for the calculation of the risk commitment period
Default risk rule
Calendar ID
Basic key figures
Validity date	Date on which the data specific to the transaction and to attribution becomes valid

Counterparty risks and issuer risks can be calculated for individual transactions, (for stock options, for example). If both risks are to be taken into account in the single transaction check, you need to supply the key of the position concerned.