country-specific functions

Application HelpPUBLIC (PUBLIC)SAP Payment EngineDocument Version: 1.5 – 2020-06-26

Country-Specific Functions

© 2

020

SAP

SE o

r an

SAP affi

liate

com

pany

. All r

ight

s re

serv

ed.

THE BEST RUN

Content

1 Country-Specific Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Russia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1 Bank of Russia Payment System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Electronic Document Message. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

2.3 Packages for Incoming and Outgoing Payments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Determination of Forwarding Status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Reconciliation of ED 211 Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4 Payment Order. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Processing of Outgoing Credit Transfers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Processing of Incoming Credit Transfers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Resubmission of Intraday and K2 Items. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.5 Direct Debit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Processing of Payment Claims. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

Processing of Expired Payment Claims. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Processing of Collection Orders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.6 Card-Index File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Processing of Card-Index Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3 United States. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.1 Clearing House Interbank Payment System (CHIPS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Message Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2 Federal Reserve Wire Network (Fedwire). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Message Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Route Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26

Payment Processes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.3 Automated Clearing House (ACH). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Standard Entry Class Codes (SEC). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4 Germany. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1 DTAZV. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2PUBLICPUBLIC

Country-Specific FunctionsContent

1 Country-Specific Functions

In this section, you can find information about how SAP Payment Engine has been localized for various countries.

Country-Specific FunctionsCountry-Specific Functions

PUBLICPUBLIC 3

2 Russia

The localization of SAP Payment Engine for Russia enables you to meet the legal requirements and conduct business according to common practices and standards in the Russian Federation.

2.1 Bank of Russia Payment System

Definition

The Bank of Russia Payment System (BRPS) is used to process non-cash settlements (in Rubles) between credit institutions in Russia. Each credit institution must be an account holder at the Central Bank of the Russian Federation, which is responsible for coordinating and regulating settlements in Russia.

When credit institutions register with the Central Bank, they obtain a unique bank identification code (BIC) and a corresponding account in the BRPS. Once registered in the BRPS, the credit institution is assigned a unique identifier in the SAP Payment Engine system. This unique identifier is mapped to the BIC.

Use

Payment orders can be transferred between credit institutions via the BRPS. They are sent in the form of XML messages that conform to the Unified Format of Electronic Banking Messages (UFEBM).

The figure below shows how these XML messages (ED* and ESID* messages) are used to transfer funds domestically via the BRPS.

4PUBLICPUBLIC

Country-Specific FunctionsRussia

Structure of the Bank of Russia Payment System

The basic process of transferring funds between credit institutions is as follows:

1. Client 1 (payer) submits a payment order to the credit institution (bank 1).2. The bank checks the payment order and sends it to the BRPS (payment center 1).3. The BRPS checks the payment order and if no errors are detected, it credits the NOSTRO account of client

2’s bank (payment center 2). Otherwise, it sends the relevant ESID message with an error code to the payer’s bank.

4. If the previous step was completed successfully, the BRPS forwards the payment order to client 2’s bank (bank 2) for processing.

5. Client 2’s bank credits the customer’s account (client 2).

More Information

For more information about how the system processes outgoing payments, see Processing of Outgoing Credit Transfers [page 11].

For more information about how the system processes incoming payments, see Processing of Incoming Credit Transfers [page 13].


PUBLICPUBLIC 5

2.2 Electronic Document Message

Definition

An electronic document message is a message in XML format that is used for data exchange between a bank and the Central Bank of the Russian Federation (CBR). ED messages can be divided into two categories:

● Financial messages have the prefix EPD (“electronic payment document”)● Non-financial messages have the prefix ESID (“electronic service information document”)

Each ED message type has the prefix “ED” followed by a three-digit number.

Use

The standard format for exchanging ED messages is UFEBM (“Unified Format of Electronic Banking Messages”). This standard is managed by the CBR and is updated periodically (approximately twice a year).

Structure

Message Types for Financial Messages

Financial messages are instructions sent between the bank and the Bank of Russia Payment System (BRPS). They have message numbers beginning with 1. The table below lists the financial message types supported by SAP Payment Engine.

Message Type Description

ED 101 Payment order

ED 103 Payment claim

ED 104 Collection order

ED 113 Instruction to create a payment claim (message ED 103). In this case, the customer is required to approve the payment. These messages are bulked together with ED 114 messages and sent using an ED 273 message (see below).

ED 114 Instruction to create a collection order (message ED 104). In this case, no customer approval is required. These messages are bulked together with ED 113 messages and sent using an ED 273 message (see below).

Message Types for Non-Financial Messages

6PUBLICPUBLIC


Non-financial messages are information messages sent between the bank and the Bank of Russia Payment System (BRPS). They have message numbers beginning with 2. The table below lists the non-financial message types supported by SAP Payment Engine.

Message Type Description

ED 201 Sent by the CBR to the bank to inform the bank of the result of formal checks that are carried out on a payment order. The original payment order is identified based on the information in the message, and its forwarding status is set based on the Customizing settings for the error codes of received messages.

ED 205 Sent by the CBR to the bank if the bank’s NOSTRO account contains insufficient funds. The original payment order is identified based on the information in the message, and its status is set based on the Customizing settings.

ED 206 Sent by the CBR to the bank to confirm that payment has been accepted and posted.

ED 211 Contains a list of transactions that have been processed by the CBR. This message type is sent by the CBR at the end of each day. The CBR can also generate this message type for a specific period upon request by the bank.

ED 273 Contains a list of ED 113 and ED 114 messages. Note that SAP Payment Engine is able to process incoming ED 273 messages but does not allow you to create them.

ED 274 Sent by the payer’s bank to the payee’s bank to notify the payee’s bank that a payment claim or collection order has been processed successfully, or that an error occurred during processing (for example, the transaction was not authorized or the payment was written to a card-index file).

Integration

Message types are modeled in SAP Payment Engine as formats, which can be defined in the Customizing activity Payment Engine File Handler Basic Settings Define Formats .


PUBLICPUBLIC 7

2.3 Packages for Incoming and Outgoing Payments

Use

Incoming and outgoing messages can be grouped into packages. The system distinguishes between electronic payment documents (EPDs) and electronic service information documents (ESIDs), and creates a package for each of these document types.

For more information about electronic documents, see Electronic Document Message [page 6].

Prerequisites

● You have configured the necessary Customizing settings for the Input Manager.

● You have defined number ranges for payment orders in Customizing for Payment Engine under Payment Order Maintain Number Ranges for Payment Orders .

● You have mapped external responses to forwarding statuses in Customizing for Payment Engine under File Handler External Response Map External Response to Forwarding Status .

● You have defined bulk types in Customizing for Payment Engine under File Handler Bulking Define Bulk Types .

● If data is to be exchanged via SAP NetWeaver, you have set up the process integration format converter in Customizing for Payment Engine under Filer Handler Process Integration Format Converter .

Features

Incoming Packages

When the XML file containing the messages is imported into the SAP Payment Engine system, the system checks the message format and the message identifier against the values defined in Customizing. Based on this information, it calls the applicable converter and the correct forwarding status is assigned to each message in the package.

Outgoing Packages

When an outbound payment order is processed, the payments are usually saved to an XML file. SAP Payment Engine enables you to specify that certain payment orders are not to be saved to this file but instead are to be send in bulk (status Waiting for Bulk).

The Russian localization of SAP Payment Engine provides a bulk type and bulk category that is specifically intended for transferring messages to the Bank of Russia Payment System (BRPS).

When the payment orders are processed, the system identifies the appropriate clearing agreement and, therefore, determines the applicable rules and bulk type. The data generated is then written to the database instead of being saved to the XML file.

8PUBLICPUBLIC


You can use the Bulk Files for Outgoing Payments transaction (/PE1/BULK_POLLER) to list all of the payment orders that have the status Waiting for Bulk. You can then select the required payments from the list and “bulk” them together to generate an outgoing file, which is then transferred to the BRPS. To access this transaction from the SAP Easy Access menu, choose Payment Engine Periodic Processing Processes Bulk Files for Outgoing Payments .

More Information

For more information about importing messages, see SAP Library for SAP Payment Engine at http://help.sap.com/banking . In SAP Library, choose File Handler (FS-PE-FH) Input Manager .

2.3.1 Determination of Forwarding Status

Use

When a payment order is created and sent to the Bank of Russia Payment System (BRPS), the system generates a unique ID for the order from the relevant number range. The incoming (response) message received from the BRPS (for example, ED 201, ED 205, or ED 206) contains a reference to the original payment order, which SAP Payment Engine uses to identify the original order during processing by the converter. The system then uses this information to assign a forwarding status for the payment order or item.

NoteIf a forwarding status has not been set for the payment order, the corresponding field is hidden on the user interface for managing payment orders.

The forwarding status is a customer-specific status with different reaction options. For example, “Sent to BRPS” or “Rejected” reactions can be defined for the confirmation messages from the BRPS.

Prerequisites

● You have defined forwarding statuses in Customizing for Payment Engine under File Handler External Response Define Forwarding Status and selected the Exception Control checkbox.

● You have mapped the external responses to the forwarding status in Customizing for Payment Engine under File Handler External Response Map External Response to Forwarding Status .

● You have defined the response types in the relevant Customizing activities under Exception ControlDefine Response Types .


PUBLICPUBLIC 9

http://help.sap.com/disclaimer?site=http%3A%2F%2Fhelp.sap.com%2Fbanking


More Information

For more information about exception handling, see SAP Library for SAP Payment Engine on SAP Help Portal at http://help.sap.com/banking . In SAP Library, choose Master Data Exception Control (FS-PE-EH) .

2.3.2 Reconciliation of ED 211 Messages

Use

You use this report to display statements that have been imported from the Central Bank of the Russian Federation (CBR) and to perform reconciliation (set the forwarding statuses of the corresponding payment orders).

Prerequisites

You have defined forwarding statuses in Customizing for Payment Engine under File Handler External Response Define Forwarding Status .

Features

This report displays the statements as a list of processed orders that have been received from the CBR via an ED 211 message. A converter reads this message format and writes the data to the database tables. SAP Payment Engine uses the references (date and ED number) of each listed payment order to identify the relevant outgoing payment orders. It then sets a confirmation forwarding status for them.

Selection

To run the report, you first enter the clearing area for which you want to review statements. The following screen displays a list of statements belonging to that payment area. By double-clicking a statement, you can view all of the associated outgoing payment orders and perform reconciliation to set a confirmation forwarding status for the correspondent orders.

Output

When you execute the report, the system issues a message stating that reconciliation has been completed.

Activities

To access this report, call transaction /PERUS/RP_RECON.

10PUBLICPUBLIC



More Information

For more information about ED messages, see Electronic Document Message [page 6].

2.4 Payment Order

Definition

A payment order is the most widely used payment method for making credit transfers in Russia. It is an account holder’s instruction to the bank to transfer a specified amount of money to the account of a payee held at the same bank or at another bank.

Use

Each payment order has a format that corresponds to the Unified Format of Electronic Banking Messages (UFEBM) and that is used to exchange XML messages with the Bank of Russia Payment System (BRPS).

Payment orders are settled using clearing agreements.

More Information

For more information about payment orders in the standard SAP Payment Engine system, see SAP Library for SAP for Banking at http://help.sap.com/banking . In SAP Library for SAP Payment Engine, choose Payment Order.

2.4.1 Processing of Outgoing Credit Transfers

Use

Outgoing credit transfers are those made from a payer’s bank to a payee’s bank. They are initiated when the payer submits a payment order to the bank, for example, as a paper document or via the Internet.

Prerequisites

The payer’s bank has a corresponding account in the Central Bank of the Russian Federation.


PUBLICPUBLIC 11


Process

The figure below shows how outgoing credit transfers are processed.

Processing of Outgoing Credit Transfers by Bank and BRPS

1. The payer submits a payment order to the bank.2. When the bank receives the payment order, the following checks are performed:

○ The system verifies that the data in the payment order is complete and correct by checking it against the customer master data.

○ The system determines whether a service fee is to be charged and if so, the account to which the charge is to be debited.

○ The system checks that the account contains enough funds to make the payment.3. The bank transfers the payment item to an intermediate account.4. The system sends message ED 101 (payment order) to the Bank of Russia Payment System (BRPS).5. The BRPS checks the data in the payment order to ensure that it is complete. If not, it sends message ED

201 to the payer’s bank and the payer’s bank rejects the payment.6. The BRPS checks that the account contains enough funds to make the payment. If not, it sends message

ED 205 to the payer’s bank and the payer’s bank sets the status of the payment order to “waiting”. If the intermediate account does not contain sufficient funds by end of day (EoD), the payer’s bank rejects the payment and the payment items are returned to the payer.

12PUBLICPUBLIC


7. If the payment order is correct and there are sufficient funds to make the payment (or sufficient funds have been received before EoD), the BRPS sends confirmation message ED 206 to the payer’s bank and the payer’s bank confirms the payment.

8. Once the bank has received message ED 206, the payment items are posted from the intermediate account to the correspondent account at the Central Bank of the Russian Federation.

9. The BRPS forwards the ED 101 message to the payee’s bank for further processing (see Processing of Incoming Credit Transfers [page 13]).

More Information

For more information about the Bank of Russia Payment System, see Bank of Russia Payment System [page 4].

For more information about ED message types, see Electronic Document Message [page 6].

2.4.2 Processing of Incoming Credit Transfers

Use

Incoming credit transfers are those received by a payee’s bank from a payer’s bank. They are initiated when the Bank of Russia Payment System (BRPS) sends message ED 101 to the bank.

Prerequisites

● The payee’s bank has a corresponding account with the Central Bank of the Russian Federation (CBR).● An outgoing credit transfer has been processed by the BRPS (see Processing of Outgoing Credit Transfers

[page 11]).

Process

The figure below shows how incoming credit transfers are processed.


PUBLICPUBLIC 13

Processing of Incoming Credit Transfers by Bank

1. The BRPS sends XML message ED 101 to the bank.2. The bank converts the message to an internal format and checks the data such as the payee’s name and

account number.3. If the data is correct, the payee’s account is credited automatically.4. If payments are incomplete by end of day (EoD), they are stored in a dedicated account for incomplete

settlements.

More Information

For more information about the Bank of Russia Payment System, see Bank of Russia Payment System [page 4].


2.4.3 Resubmission of Intraday and K2 Items

Use

You use this report during exception handling to resubmit payment orders and payment items that have a waiting status to straight-through processing (STP).

14PUBLICPUBLIC


Features

This report resubmits the payment orders and items that have been placed in the intraday queue (card-index file K2) for further processing. To do so, it sorts the orders and items in the queue and creates one package for each account. Each package can then be processed sequentially or in parallel.

When the system sorts the payment orders and items in the queue, it prioritizes them first by account, then by priority, and finally by object date. You can change this behavior using BAdI /PERUS/BADI_ASYNC_RSUB_LOGIC.

Selection

You can select parameters to determine the payment orders and payment items to be evaluated by the report and to determine how payment orders and payment items are processed.

Output

If the payment is processed successfully (for example, it is assigned the status 31 [Posted]), the system continues to process the next payment.

If an exception or error occurs, or if the payment is assigned a non-final status, the system enters a message in the log (transaction SLG1) and stops processing the items in this package.

In some cases, the Account Management system may not provide a response for the payment item. In these cases, the system makes a number of attempts to resubmit the item (based on the values in the Waiting Time and No. of Retries fields) and if resubmission fails, it skips the item. The item is then included in the next resubmission run.

Activities

To access this report from the SAP Easy Access screen, choose Payment Engine Periodic ProcessingCountry-Specific Functions Russia Resubmit Failed Payment Orders .

Example

Payments from two accounts have been entered into the intraday queue (card-index file K2):

Account 1

Payment Amount (RUB) Priority

1 100 6

2 700 2

3 50 2


PUBLICPUBLIC 15

Account 2


4 10 2

5 120 2

When the system sorts the payments, it does so first by account, then by priority, and finally by object date, resulting in the following order:


2 700 2

3 50 2

1 100 6

5 120 1

4 10 2

When the packages are created, the system creates packages for each account, whereby the payments in each package are sorted in the order specified:

Package 1


2 700 2

3 50 2

1 100 6

Package 2


5 120 1

4 10 2

16PUBLICPUBLIC


2.5 Direct Debit

A direct debit is an arrangement made with a bank that allows a third party to transfer money from a person’s account on a specific date. Direct debits can be divided into the following categories:

Payment Claims

A payment claim is a demand made by a payee (creditor) to a payer (debtor) to pay a specified amount by debiting the payer’s account on the basis of an agreement. Payments made in this way require the payer’s express authorization, which can be (but is not always) granted in advance. The bank then withdraws the amount from the payer’s account and performs credit processes for the payee.

Collection Orders

A collection order is a payment document that is used to withdraw funds from a payer’s account without the payer’s approval. They are used, for example, in the following cases:

● When an indisputable funds withdrawal procedure is established by law● When a court decision has established the right to withdraw funds● When agreed by counterparties and the payer’s bank has been authorized to withdraw funds from the

customer’s account without the customer’s specific instruction

2.5.1 Processing of Payment Claims

Use

Instructions to create payment claims (message ED 113) are transferred between banks in bulk using message format ED 273. When the bank receives the ED 273 message, it processes each ED 113 and responds to the Bank of Russia Payment System (BRPS) using message ED 274.

Before SAP Payment Engine can process a payment claim, the customer must authorize the payment. The payment claim is therefore placed in card-index file K1 and the customer contacted by the bank within 5 days of receiving the claim (or by the due date if a due date has been specified).

Once the customer has authorized the payment, the bank generates a payment claim and transfers message ED 103 to the BRPS. This process is similar to that for processing payment orders (see Processing of Outgoing Credit Transfers [page 11]).


PUBLICPUBLIC 17

Process

The figure below shows the process with which payment claims are transferred between banks.

Processing of Payment Claims in SAP Payment Engine

1. When a customer presents a payment claim to the bank, a direct debit is initiated.2. The bank validates the documents and adds the payment claim to the register of collection payment

documents.3. All of the payment claim instructions (ED 113 messages) are bundled together with collection order

instructions (ED 114 messages) into an ED 273 message.4. The payment claims are sent to the payer’s bank in the form of the ED 273 message.5. On receiving the message, the payer’s bank registers and validates each ED 113 message and provides

responses to the BRPS in the form of an ED 274 message.6. If the customer (payer) has not already authorized the payment, the payment amount is entered into card-

index file 1 (K1). The bank posts the appropriate amounts to an off-balance account. Once the customer has authorized the payment, the reverse postings are made.

7. The payer’s bank initiates the funds transfer by creating message ED 103 and sending it to the BRPS.8. In the event of insufficient funds, the payment amount is entered in card-index file K2. Payments can be

stored in card-index file K2 for an unlimited period of time. The bank posts the appropriate amounts to an off-balance account.

18PUBLICPUBLIC


NoteThis off-balance account is not the same as the one used to post amounts to card-index file K1.

More Information

For more information about card-index files, see Card-Index File [page 21].


2.5.2 Processing of Expired Payment Claims

Use

You use this report to explicitly deny the approval of payment orders that have had the status Waiting for Authorization (status 174) for too long. Payment order authorization is considered to have expired if the due date is earlier than the current reconciliation date.

The report is intended to be run as part of end-of-day processing.

Features

Selection

You specify the clearing area for which you want to find payment orders, along with the reconciliation date (current date).

The External Error field is evaluated together with the authorization checkbox in the payment order. For more information about external errors, see Customizing for Payment Engine under Exception Control Exception Handling Maintain External Errors .

The Annotation field enables you to enter a comment as free text.

The Info Code field enables you to specify the reason for which the payment order is to be rejected. In the case of expired payment claims, set this value to 5 (rejected due to lack of approval).

You can select the Show Result and Simulation checkboxes to specify whether you want the system to display the results of the report in an ALV grid and whether you want to simulate the results of the report before executing it as part of a live run.

Output

When the report is executed, it checks the reconciliation date against the due date for all payment orders awaiting authorization. If any payment order has not been authorized by the due date, it is rejected.

The output of the report shows a table that lists the rejected payment orders.


PUBLICPUBLIC 19

Activities

You access this report by calling transaction /PERUS/EXP_CLAIMS.

2.5.3 Processing of Collection Orders

Use

Instructions to create collection orders (message ED 114) are transferred between banks in bulk using message format ED 273. When the bank receives the ED 273 message, it processes each ED 114 and responds to the Bank of Russia Payment System (BRPS) using message ED 274.

On receipt of the ED 273 message, the bank generates a collection order and transfers message ED 104 to the BRPS. This process is similar to that for processing payment orders (see Processing of Outgoing Credit Transfers [page 11]).

Process

The figure below shows how collection orders are processed in SAP Payment Engine.

Processing of Collection Orders in SAP Payment Engine

1. When a customer presents a collection order to the bank, a direct debit is initiated.2. The bank validates the documents and adds the collection order to the register of collection payment

documents.

20PUBLICPUBLIC


3. All of the collection order instructions (ED 114 messages) are bundled together with payment claim instructions (ED 113 messages) into an ED 273 message.

4. The collection orders are sent to the payer’s bank in the form of the ED 273 message.5. On receiving the message, the payer’s bank registers and validates each ED 114 message and provides

responses to the BRPS in the form of an ED 274 message.6. The payer’s bank initiates the funds transfer by creating message ED 104 and sending it to the BRPS.7. In the event of insufficient funds, the payment amount is entered in card-index file K2. Payments can be

stored in card-index file K2 for an unlimited period of time. The bank posts the appropriate amounts to an off-balance account.

2.6 Card-Index File

Definition

Card-index files group payment orders that have a specific status. There are two card-index files: K1 and K2.

● K1 contains payment orders that are awaiting authorization from the client. It also contains payment orders that relate to a client’s account that has been frozen. Incoming ED 113 messages that need client approval are entered into card-index file K1. In other words, if a payment order is assigned the status Waiting for Authorization (technical status 174), it is added to card-index file K1.

● K2 contains payment orders for which the bank account does not contain enough funds.

NoteThis is the account held at the client’s bank and not the correspondent account at the Central Bank of the Russian Federation (CBR).

Integration

If a payment order is entered into a card-index file, message ED 274 is sent to the requestor’s bank (via the CBR) to inform the recipient of the status change.

When an order is added to a card-index file, a posting is automatically made to an off-balance account. This is done by adding a payment item to the payment order and posting it. This payment item is then transferred to SAP Transactional Banking where it is processed further.

More Information

For more information about ED messages, see Electronic Document Message [page 6].


PUBLICPUBLIC 21

2.6.1 Processing of Card-Index Files

Use

Accounting for card-index files (K1 and K2) must be carried out in accordance with the applicable Russian legislation. Account Management (FS-AM) contains enhancements that enable you to perform accounting processes for card index files in SAP Bank Analyzer (FS-BA) and hold funds for partial payments.

Features

Card-Index File 1

The bank receives a request to make a payment to a customer. The request must first be authorized by the account holder.

● SAP Payment Engine (FS-PE) stores the payment document in card-index file 1 and generates a debit posting to a G/L off-balance account. It also generates a prenote to credit the customer’s account.

● Account Management processes the debit in the G/L off-balance account along with the prenote for the customer’s account.

The bank submits the authorization request to the customer. If the customer authorizes, partially accepts, or rejects the payment request, SAP Payment Engine releases the request and generates a credit to a G/L off-balance account. It also clears the prenote for the customer’s account and triggers a debit of the customer’s account in Account Management. Account Management posts the credit in the G/L off-balance account and processes the debit to the customer’s account.

Card-Index File 2

The bank receives a request to make a transfer from a corporate customer. However, the customer’s account has insufficient funds to cover the debt.

1. Account Management uses a formal payment-item check to verify whether the customer’s account contains enough funds to cover the entire debit. If the funds are not available, Account Management rejects the item.

2. SAP Payment Engine creates an intraday queue and generates a prenote. By doing so, it reserves the payment amount in SAP Transactional Banking and adds the payment item to the queue for automatic resubmission.

The bank now receives another request to make a payment to the same customer. At this point, the customer’s account contains enough funds to cover the debt.

● SAP Payment Engine does not debit this payment since the amount is reserved in Account Management for the previous debt (via the prenote). SAP Payment Engine also generates a new prenote for this new debt.

At the end of the day, SAP Payment Engine attempts to reprocess the payments. It moves any remaining payment requests in the intraday queue to the K2 file and generates a debit to a G/L off-balance account. Account Management uses an internal account to hold the funds in the K2 file.

The bank sends a notification to the payees and the payer via SAP Payment Engine. On the next day, the bank’s corporate customer deposits enough money to cover both debts. During the next payment run, the system

22PUBLICPUBLIC


removes the payment requests from the K2 file (by crediting the G/L off-balance account and clearing the prenote). In Account Management, the funds are then debited from the account that holds the K2 file amounts.


PUBLICPUBLIC 23

3 United States

The localization of SAP Payment Engine for the United States enables you to meet the legal requirements and conduct business according to common practices and standards in the United States.

3.1 Clearing House Interbank Payment System (CHIPS)

The Clearing House Interbank Payments System (CHIPS) is an electronic payments system that is used to transfer and settle large-value domestic and international payments in U.S. dollars. When financial institutions send and receive payments, CHIPS matches, offsets, and releases the payments. This enables customers to receive payments during the local business day, regardless of where they are in the world.

CHIPS is owned by the financial institutions (“members”) that use it

3.1.1 Message Types

Definition

SAP Payment Engine supports the following message types, which are based on the File Handler:

● CHIPS AcknowledgementThis message is sent to the participant by CHIPS and is used to update the transaction status.

● Initial End-of-Day Balance ReportThis settlement report is output from CHIPS to a participant.

● Participant AcknowledgementThis message is sent to CHIPS by the participant and is used to update the transaction status.

● CHIPS Payment MessageThis message specifies the outbound credit transfer to CHIPS.

● CHIPS Receive NotificationThis message specifies the incoming message from CHIPS.

● Status / Recovery / Closing ReportThis settlement report is output from CHIPS to a participant.

Integration

The messages are converted into an internal format using XML converters. You can set up the converters in Customizing for Payment Engine under File Handler Basic Settings Maintain Converter and File Handler XML Converter Development Define Converter Implementation for Format Converter .

24PUBLICPUBLIC

Country-Specific FunctionsUnited States

More Information

3.2 Federal Reserve Wire Network (Fedwire)

The Federal Reserve Wire Network, commonly known as Fedwire, is a real-time gross settlement system (RTGS) operated by the U.S. Federal Reserve Banks. It is used to process high-value and time-critical transactions both domestically and internationally.

3.2.1 Message Types

Definition

SAP Payment Engine supports the following message types, which are based on the File Handler:

● BTR (Bank Transfer)● CKS (Check Same Day Settlement)● CTP (Customer Transfer Plus)● CTR (Customer Transfer)● DEP (Deposit to Sender’s Account)● DRB (Bank-to-Bank Drawdown Request)● DRC (Customer or Corporate Drawdown Request)● DRW (Drawdown Payment)● FFR (Fed Funds Returned)● FFS (Fed Funds Sold)● SVC (Service Message)

Integration

The messages are converted into an internal format using XML converters. You can set up the converters in Customizing for Payment Engine under File Handler Basic Settings Maintain Converter and File Handler XML Converter Development Define Converter Implementation for Format Converter .

More Information


PUBLICPUBLIC 25

3.2.2 Route Processing

Use

SAP Payment Engine uses an internal routing directory to identify participants as defined in the Fedwire directory. The routing directory is then used in route processing to forward transactions to the appropriate participants.

You upload the Fedwire directory to SAP Payment Engine in the Upload Referential Data transaction (/PE1/UPLOAD_RD), which you can access on the SAP Easy Access menu by choosing Payment EngineReferential Data Upload Referential Data .

More Information

3.2.3 Payment Processes

Use

Credit Transfer

Credit transfers are initiated when a participant instructs a Federal Reserve Bank to debit funds from the participant's account and credit them to another participant's account. The funds are transferred using automated, straight-through processing (STP), which includes enrichment and validation, route processing, and clearing and settlement.

Reversal

Transactions that are carried out through Fedwire can be reversed in the same way as in other countries around the world and in accordance with ISO 20022. Request agents are used to track incoming requests and monitor their status. If a payment transaction is recalled, responses can be sent automatically in the form of a DRB, DRC, or SVC message.

Drawdown

Drawdowns are requests to transfer funds from an external account to a dedicated beneficiary. They require manual approval and are handled in the same way as cash pooling with requests for transfer.

Service Messages

Service messages are non-financial messages that are exchanged between participants and that are not covered by other Fedwire message types. You can create and display non-financial messages directly on the user interface (transaction /PE1/INVEST).

For example, reversal requests generate the respective recall or request agent objects.

26PUBLICPUBLIC


More Information

For more information about credit transfers, see:

●●●●

For more information about reversals, see .

For more information about drawdowns, see .

For more information about service messages, see .

3.3 Automated Clearing House (ACH)

Automated Clearing House (ACH) is a batch processing system run by the National Automated Clearing House Association (NACHA), that is used for electronic funds transfers.

3.3.1 Standard Entry Class Codes (SEC)

Automated Clearing House (ACH) uses Standard Entry Class (SEC) codes. These three character codes identify payment type and formatting requirements.

The Standard Entry Class codes used are as follows:

ACH Standard Entry Class Codes (SEC)

Code Type Code Description

Consumer Codes CIE Customer Initiated Entry

DNE Death Notification Entry

ENR Automated Enrollment Entry

PPD Preauthorized Pay / Deposit Entry

RCK Represented Check Entry

TEL Telephone Initiated Entry

WEB Internet Initiated / Mobile Entry

Consumer / Corporate Codes ARC Accounts Receivable Conversion Entry

POP Point of Purchase Entry

BOC Back Office Conversion

TRC Truncated Check Entry


PUBLICPUBLIC 27

Code Type Code Description

TRX Truncated Check Entries Exchange

XCK Destroyed Check Entry

IAT International ACH Transaction

Corporate Codes ACK Acknowledgment Entry

ATX Financial EDI Acknowledgment Entry

CCD Corporate Credit or Debit Entry

CTX Corporate Trade Exchange

Debit Card / POS Entry Codes MTE Machine Transfer Entry

POS, Point of Sale Entry

SHR Shared Network Transaction

Other Codes ADV Statement of Activity (ACH Format)

COR Correction (Notification of Change (NOC)) Entry

28PUBLICPUBLIC


4 Germany

The country-specific functions of SAP Payment Engine for Germany enable you to meet the legal requirements and conduct business according to common practices and standards in Germany.

4.1 DTAZV

DTAZV (Datenträgeraustauschverfahren für den Auslandszahlungsverkehr) is an electronic payment system used in Germany for international payments. It was developed by Die Deutsche Kreditwirtschaft.

Country-Specific FunctionsGermany

PUBLICPUBLIC 29

Important Disclaimers and Legal Information

HyperlinksSome links are classified by an icon and/or a mouseover text. These links provide additional information.About the icons:

● Links with the icon : You are entering a Web site that is not hosted by SAP. By using such links, you agree (unless expressly stated otherwise in your agreements with SAP) to this:

● The content of the linked-to site is not SAP documentation. You may not infer any product claims against SAP based on this information.● SAP does not agree or disagree with the content on the linked-to site, nor does SAP warrant the availability and correctness. SAP shall not be liable for any

damages caused by the use of such content unless damages have been caused by SAP's gross negligence or willful misconduct.

● Links with the icon : You are leaving the documentation for that particular SAP product or service and are entering a SAP-hosted Web site. By using such links, you agree that (unless expressly stated otherwise in your agreements with SAP) you may not infer any product claims against SAP based on this information.

Videos Hosted on External PlatformsSome videos may point to third-party video hosting platforms. SAP cannot guarantee the future availability of videos stored on these platforms. Furthermore, any advertisements or other content hosted on these platforms (for example, suggested videos or by navigating to other videos hosted on the same site), are not within the control or responsibility of SAP.

Beta and Other Experimental FeaturesExperimental features are not part of the officially delivered scope that SAP guarantees for future releases. This means that experimental features may be changed by SAP at any time for any reason without notice. Experimental features are not for productive use. You may not demonstrate, test, examine, evaluate or otherwise use the experimental features in a live operating environment or with data that has not been sufficiently backed up.The purpose of experimental features is to get feedback early on, allowing customers and partners to influence the future product accordingly. By providing your feedback (e.g. in the SAP Community), you accept that intellectual property rights of the contributions or derivative works shall remain the exclusive property of SAP.

Example CodeAny software coding and/or code snippets are examples. They are not for productive use. The example code is only intended to better explain and visualize the syntax and phrasing rules. SAP does not warrant the correctness and completeness of the example code. SAP shall not be liable for errors or damages caused by the use of example code unless damages have been caused by SAP's gross negligence or willful misconduct.

Gender-Related LanguageWe try not to use gender-specific word forms and formulations. As appropriate for context and readability, SAP may use masculine word forms to refer to all genders.

30PUBLICPUBLIC

Country-Specific FunctionsImportant Disclaimers and Legal Information

Country-Specific FunctionsImportant Disclaimers and Legal Information

PUBLICPUBLIC 31

www.sap.com/contactsap

© 2020 SAP SE or an SAP affiliate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affiliate company. The information contained herein may be changed without prior notice.

Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors. National product specifications may vary.

These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP or its affiliated companies shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP or SAP affiliate company products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other countries. All other product and service names mentioned are the trademarks of their respective companies.

Please see https://www.sap.com/about/legal/trademark.html for additional trademark information and notices.

THE BEST RUN

https://www.sap.com/about/legal/trademark.html

country-specific functions

Documents