Show TOC

Object documentationService Level Agreement Locate this document in the navigation structure


An agreement between a financial institution and its customers that defines various conditions for senders of payment orders.

This information is relevant to the enrichment and validation process, in particular, the enrichment of payment transaction data and the clearing and settlement process. It also defines how the system processes payment orders and payment items.


You use service level agreements (SLAs) to define different values and validation criteria (for example, the error percentage allowed) that are used in the enrichment and validation process. SLAs also ensure that payment orders and payment items meet the requirements of a financial institution based on negotiations between the account managers and the customers of the financial institution.

You can set the system up so that the payment order is also sent to exception handling if the percentage of incorrect recipient items exceeds a threshold value that you define.

The following SLA types are used for each payment item:

  • Clearing area SLA

    A generic SLA stored at clearing area (branch) level.

    You use clearing area SLAs to stipulate requirements (formal and material) that payment orders and payment items have to comply with to ensure seamless payment processing in Payment Engine.

  • Customer segment SLA

    An SLA stored at customer segment level.

    You use customer segment SLAs to define special conditions for groups of customers, such as VIPs, high-income earners, or families.

  • Customer SLA

    An SLA stored at customer level that is only applicable to individual customers.

    You use customer SLAs to define special customer requirements or special customer agreements with the financial institution.

Many of the formal and material checks depend on the SLA determined for the payment item that is being processed. The SLA defines not only the checks that the system performs but also process-specific information that is used in the actual processing of the payment items.

You can define the following conditions or restrictions in SLAs:

  • Specified payment products and channels

    A customer is only allowed to use certain channels and payment products.

  • Payment amount limit

    For certain payment products, a customer must not exceed certain amounts when sending payment orders to a financial institution.

    Example Example

    In the context of wholesale banking, a customer cannot send domestic payment orders for amounts that exceed €10,000,000. This limit is not comparable to the credit limit or the actual amount available to the customer on the account that is stored in the authorization or credit-limit-check application.

    End of the example.
  • Cut-off time

    A customer who sends payment orders to Payment Engine has to comply with certain cutoff times to ensure that the financial institution can process the payment within a given business day.

    Example Example

    A customer is limited to sending retail mass payments before 11:00 a.m. if the financial institution is to guarantee processing within the same business day.

    End of the example.
  • Transaction type lock

    Certain transaction types can be locked for certain customers even though these customers are allowed to use the payment product and channel.

    You can also restrict certain transactions in certain bank countries as part of country risk management. Depending on your settings, the system validates recipient items, checking first the settings for the customer SLA, then the segment SLA, and then the clearing SLA. You can specify what is to happen if a recipient item fails the validation and goes to exception handling. There, the system determines the defined response for the error, for example, whether to send items to postprocessing, or ignore them.

    Example Example

    A customer may be allowed to send salary payments by using the corporate gateway channel but may not be allowed to send direct debits using this channel.

    In country risk management, a bank might decide that a particular country is too risky for credit transfers.

    End of the example.

You manage SLAs as follows:

On the SAP Easy Access screen, choose   Payment Engine   Master Data   Service Level Agreements   Manage Service Level Agreements   (transaction /PE1/SLA). For more information, see Managing Service Level Agreements.


An SLA is similar to a route or a clearing agreement in that it specifies information that determines how the system processes payments.

An SLA comprises the following:

  • Basic Datatab page

    Displays basic data such as the SLA status and type, and information about assigned accounts.

  • SLA General tab page

    Displays additional information required for the enrichment and validation process and the clearing and settlement process. This enables you to lock customer SLAs, so that the system sends all payment orders for the customer to exception handling.

    Note Note

    On this tab page you can assign a charge group for payment transactions based on financial conditions. This enables you to determine the charges during enrichment and validation as the ordering institution. You can also validate incoming OUR charges during enrichment and validation when you receive messages, for example, SWIFT MT 103+.

    Based on your Customizing settings, you can edit the charge conditions. From the SAP Easy Access menu, choose   Payment Engine   Master Data   Charges  . To make the required settings in Customizing for Payment Engine (FS-PE), choose   Charges  .

    You can use different characteristics to determine if the condition is used. These include the following:

    • BIC

    • Charge category

    • Transaction type

    • Payment order type

    • Ability to be processed in straight-through-processing

    You can define and assign additional characteristics in Customizing for Payment Engine (FS-PE), under   Charges  . You can add more characteristics by implementing the Business Add-In (BAdI) BAdI: Assignment of Differentiation Values for Charges in Customizing for Payment Engine (FS-PE), under   Charges   Business Add-Ins (BAdIs)  . This BAdI determines which particular value applies during runtime to a specific differentiation criteria and if a charge is thus to be applied. You can define the list of possible values for additional differentiation categories by implementing Business Add-In (BAdI) BAdI: Definition of Additional Differentiation Categories in Customizing for Payment Engine (FS-PE), under   Charges   Business Add-Ins (BAdIs)  .

    For more information about financial conditions, see SAP Library at, under   SAP for Industries   SAP for Banking   Banking Services from SAP   Release Banking Services from SAP 8.0   Financial Conditions (CA-FIM-FCO)  .

    End of the note.
  • SLA Submission Data tab page

    Displays a combination of channel, medium, and format. Payment orders that match the defined filter options are enriched with the SLA information.

  • Order Type Data tab page

    Displays the formal and material checks defined in the SLA that are applied to payment orders of the payment order type specified in this filter and also provides a check of the percentage of items with errors.

  • Trans Type Data tab page

    Displays the defined formal and material checks defined in the SLA that are applied to the payment orders with payment items of the transaction type specified in this filter.

    In the Country Restrictions group box, you can specify that a certain country cannot receive bank transfers by specifying either the transaction type or group, and the country, and selecting the Country Not Allowedcheckbox.

  • Admin Data tab page

    Displays the name of the creation, change, and release user with the date and time.


SLAs are integrated in enrichment and validation checks and also in the clearing and settlement process to perform additional checks of all payment orders and payment items for which the system finds an applicable SLA.

If a condition is not met in an SLA, Payment Engine automatically triggers exception handling to evaluate the error and determine an appropriate response.

For more information about exception handling in Payment Engine, see Exception Control (FS-PE-EH).