04 workingpaper paymentengine english

8/18/2019 04 WorkingPaper PaymentEngine English

1/44

®

SAP for Banking

SAP FOR BANKING

PAYMENT ENGINE

THE PAYMENT TRANSACTION

SOLUTION FOR BANKS

Page 1 of 44


2/44

CONTENTS 1 INTRODUCTION ..............................................................................................3

1.1 POSITIONING OF THE PAYMENT ENGINE AND SAP FOR BANKING.......... 3 1.2 CHANGING PAYMENT TRANSACTIONS ............................................................. 3

2 PAYMENT ENGINE – CLASSIFICATION AND OVERVIEW...................5 3 PAYMENT ENGINE COMPONENTS IN DETAIL.....................................10

3.1 FILE HANDLER – INPUT MANAGER ................................................................... 10

3.2 PAYMENT PROCESSING ...................................................................................... 14

3.3 ROUTE PROCESSING............................................................................................ 16

3.3.1 ROUTE ....................................................................................................................... 16

3.3.2 CLEARING AGREEMENT....................................................................................... 18

3.3.3 CUSTOMER AGREEMENT .................................................................................... 20

3.3.4 VALUE DATE AGREEMENT .................................................................................. 20

3.4 CLEARING AND SETTLEMENT ............................................................................ 22

3.4.1 COLLECTOR............................................................................................................. 22

3.4.2 QUEUE ....................................................................................................................... 24

3.5 FILE HANDLER – OUTPUT MANAGER............................................................... 26

3.6 EXCEPTION CONTROL AND POSTPROCESSING IN THE PAYMENTENGINE ...................................................................................................................... 27

4 PAYMENT ENGINE - CHARACTERISTICS .............................................31

4.1 MULTI-CLIENT CAPABILITY.................................................................................. 31

4.2 NON-FORMAT DEPENDENT PROCESSING OF DOMESTIC AND FOREIGNPAYMENT TRANSACTIONS.................................................................................. 32

4.3 TRANSPARENCY..................................................................................................... 33

4.4 PERFORMANCE ...................................................................................................... 34

4.5 MIGRATION STRATEGY ........................................................................................ 34

5 PAYMENT ENGINE – OTHER FUNCTIONS ............................................35

5.1 CLEARING SCENARIOS ........................................................................................ 35

5.2 CURRENCY EXCHANGE ....................................................................................... 36

5.3 END-OF-DAY PROCESSING ................................................................................. 37

5.3.1 ACCRUAL .................................................................................................................. 37

5.3.2 RECONCILIATION ................................................................................................... 38 5.4 AUTHORIZATION CONCEPT ................................................................................ 39

5.5 RECALLS ................................................................................................................... 39

5.6 RELEASE................................................................................................................... 40

5.7 CORRESPONDENCE .............................................................................................. 41

6 SUMMARY ......................................................................................................42 7 THE WAY AHEAD .........................................................................................43

No part of this publication may be reproduced or transmitted in any form or for any

purpose without the express permission of SAP AG. The information contained herein

may be changed without prior notice.

Page 2 of 44


3/44

1 INTRODUCTION

1.1 POSITIONING OF THE PAYMENT ENGINE AND SAP FOR

BANKING

In the last few years, SAP has developed an application landscape for banks, oriented

towards the needs of international financial institutions. The individual applications of

this business-oriented architecture are solutions and integral solution components of

SAP for Banking. SAP Core Banking allows you to optimize your account processes.

The Payment Engine (PE) is a component of this integrated solution. As an independent

payment transaction solution for mass data processing, it is the central component

between external clearing systems and internal account-managing systems.

1.2 CHANGING PAYMENT TRANSACTIONS

The general conditions of payment transactions have changed fundamentally in the last

few years. Since the introduction of the Euro, a large amount of payment transactions in

Europe are classed as domestic payment transactions. EU legislators are demanding that

the time and customer charges for Euro bank transfers within the Euro countries are

lowered in line with the charges for a domestic bank transfer. With clearing systems like

European Banking Association (EBA) STEP 1 and STEP 2, the first steps towards a

Single European Payments Area (SEPA) have been implemented.

Price and service conscious customers, as well as the increasing complexity of new

clearing procedures, are creating enormous pressure to identify potential cost-saving

measures in payment transactions. The aim is Straight Through Processing (STP) of

payment orders.

The need to reduce costs is important to the central idea of insourcing and outsourcing

models. Potential cost savings are seen when grouping similar activities together, not

only in payment transactions. These services can then be offered to third parties. The

trend is moving towards transaction banks that process large volumes due to their

concentration and can therefore work more efficiently and lower unit costs. These

transaction banks are based on a different business model to traditional universal banks.

The payment transaction system requires more flexibility (“real client capability”) in

order to reflect new business models.

New clearing procedures such as CLS clearing demand real-time processing of payment

orders. The possibility of calculating intraday interest is also important in this context.

With regard to today’s demands, the payment transaction systems that have developed

in banks prove to be inflexible as it takes a disproportionate effort to maintain and

enhance them.

Page 3 of 44


4/44

To optimize the processing of payment transactions within large banks, IT centers and

transaction banks, SAP is developing the standard solution Payment Engine.

Page 4 of 44


5/44

2 PAYMENT ENGINE – CLASSIFICATION AND

OVERVIEW

As a component of SAP for Banking, Payment Engine controls the real-time processing

of payment orders, twenty-four hours a day, seven days a week . As an independent payment transaction component for mass data processing, it is the central component

between external clearing systems and internal account-managing systems.

The first step is the direct connection of the two SAP account-managing systems,

Account Management (AM) and Bank Customer Accounts (BCA). The open system

architecture of Payment Engine also allows other account-managing systems to be

connected. The Payment Engine provides functions for determining the account-

managing system and for distributing payment items between different systems.In view of the EU Commission regulation on cross-border payments in Euro and the use

of potential cost-savings, Payment Engine supports the observance of STP criteria (such

as the use of IBAN and BIC).

Figure 1: The Payment Engine in SAP Core Banking

The Payment Engine is distinguished by a generic architecture with the aim of

independent usability in the payment transactions of large banks, IT centers and

transaction banks. Customer-specific enhancements can be implemented without

changing the standard development. It offers well-defined interfaces to feeder and

Page 5 of 44


6/44

forwarding systems using standard interface technology. This means that Payment

Engine can be integrated into an existing system landscape with different upstream and

transfer systems.

The Payment Engine is based on the SAP NetWeaver technology platform, which

connects systems and integrates company processes. In this way, SAP is creating the

technological basis for the flexible realization of your business strategies. The Payment

Engine also has standard functions such as client-capability, multiple languages,

multiple currencies and technical system platform independence.

Figure 2: Overview of Payment Engine

The Payment Engine architecture consists of the following three components:

Payment Processing

Route Processing

Clearing and Settlement

A File Handler is also supplied as an input and output component for Payment Engine.

The File Handler consists of:

Input Manager

Page 6 of 44


7/44

Output Manager

The Payment Engine also provides flexible functions for exception control andpostprocessing, thus enabling you to configure the possible system responses to errors

that occur during payment order processing.

The individual components of Payment Engine are described in more detail in the

following sections. The figure below illustrates processing within Payment Engine. For

example, the processing of a payment order is described with the following conditions:

Input format: Data Medium Exchange (DME) collective payment order

All recipient items go to different banks and are assigned to the same external

route

The creation of a collector is scheduled in the clearing agreement for thisexternal route

Clearing

And

Settlement

Route

Processing

Proxy

(Interface)

Account

Management

System

SAP AM/BCA

Input Manager

4

Output Manager

FileHandler

Database

2

2013

Rec.

PI

R

CA

19

Collective PO

in PE

Metaformat

18Collect

PO

11

OP

PI

R

CA8

OP

PI

9

17

Clear

PI

Route (R)+

Clearing Agreement

(CA) 6

Format

Converter

Format

Converter

Non SAP componentAP component

File Handler

5OP

PI10

Rec.

PI

Rec.

PI14

R

CA

ClearingCollector

16

DME

File

1

12Value Date Agreement

7

21

Target

Format

15 F e e d e r a n d F o

r w a r d i n g

S y s t e m

s

AdditionalData

3

Payment

Orders in

Metaformat

PO in PE

Metaformat

PaymentProcessing

Payment Engine

Figure 3: Example Processing of a DME File

Process description of the fully automated processing:

1. The feeder system (such as file management) receives a new file (here in DME

format) and calls up the Input Manager with information on this file (channel,

medium, format and path). The Input Manager recognizes the correct customer

format converter from the channel, medium and format. The format converter

reads the file and maps the input format to Payment Engine metaformat. All

Page 7 of 44


8/44

format-dependent checks and necessary derivations are also done in the format

converter.

2. After the check and mapping in the customer format converter, the Input

Manager transfers the data. All fields of the original payment order or payment

item that are not required for processing in Payment Engine can be stored in the

File Handler database. This means that the Output Manager still has all of the

original data available, if information on the incoming payment order is to be

placed in an outgoing payment order after processing.

3. The Input Manager transfers the payment order data in Payment Engine

metaformat for saving in the Payment Processing component. The metaformat

contains payment orders including payment items and remittance data.

4. The payment order, including all payment items, is formally checked in Payment

Processing.

5. The ordering party item is first transferred from the Payment Processing

component to the Route Processing component for determination of the route

and clearing agreement.

6. In Route Processing, the route and associated clearing agreement are determined

for this ordering party item.

7. The value date agreement for the ordering party item is also determined in Route

Processing.

8. The ordering party item, enhanced with the route and clearing agreement, is

transferred to the Clearing and Settlement component.

The system uses the route and associated clearing agreement to determine that

the ordering party item is to be posted internally in the bank, in a connected

account-managing system. (Note: The ordering party item always has to be

internal).

9. Using a proxy, the ordering party item is forwarded to the account-managing

system for posting control and prenote, or posting. Whether an item is subjected

to posting control and prenote or posted directly depends on the functions

provided by the account-managing system. The account-managing systemreturns a positive or negative confirmation.

10. After successful posting control and prenote or posting of the ordering party

item, the recipient items are transferred to the Route Processing component.

Steps 11-14 are repeated for each recipient item.

11. The route and associated clearing agreement are determined for the ordering

party item in Route Processing.

12. The value date agreement is also determined for the recipient item in Route

Processing.

13. The recipient item, enriched with the route and clearing agreement, is transferred

to the Clearing and Settlement component. In this component, the system uses

Page 8 of 44


9/44

the route and clearing agreement information to decide how the recipient item is

processed.

14. In this example, the route and clearing agreement are used to determine that therecipient item is external and is to be placed in a clearing collector. The recipient

item is therefore placed in an open clearing collector.

15. If a prenote was created for the ordering party item in account management in

step 9, this is deleted after all recipient items have been successfully posted. This

completes processing of the incoming payment order in Payment Engine.

16. The closing criteria for the clearing collector (such as number of items and total

of items) are registered in the clearing agreement. They are constantly checkedand updated by an independent process, separate from the primary process. Thesystem also checks whether the collector needs to be closed when a preset time

is reached. The clearing collector is closed when a closing criterion occurs.

17. When the clearing collector is closed, a clearing item (collector total) is

generated. The clearing item is booked in the relevant account-managing system.

18. A new outgoing collective payment order including all payment items in the

clearing collector is then created as a recipient item and a new ordering party

item. The outgoing collective payment order is forwarded from Clearing to the

Output Manager.

19. Information on the outgoing collective payment order is transferred to the

Output Manager in Payment Engine metaformat. In the case of large payment

orders, the Output Manager reads the collective payment order transferred inmetaformat in batches.

20. The File Handler recognizes the correct customer format converter from the

channel, medium and target format. The format converter maps the outgoingmetaformat to the target format. All fields and information from the original

payment order are available in principle during mapping (partially read from the

File Handler database by the File Handler and derived from the outgoing

payment order in metaformat and provided to the format converter. See point 2). Additionally, any format-dependent checks on the outgoing payment order are

made in the format converter .

21. The customer format converter transfers the created payment order to therelevant transfer system in target format .

Page 9 of 44


10/44

3 PAYMENT ENGINE COMPONENTS IN DETAIL

3.1 FILE HANDLER – INPUT MANAGER

Figure 4: Integration of File Handler (Input Manager) in the Overall Process

As there are many different formats in worldwide payment transactions, sometimes

specific to the country, a customer format converter is required in the Input Manager.

This format-dependent element is not included in the SAP standard system. The

customer or SAP implementation partner must implement and be responsible for this.The conversion to Payment Engine metaformat guarantees format-independent

processing in Payment Engine. This procedure also ensures that customer-specific and

internal payment order formats can be implemented easily and quickly.

A standard framework is provided to support the customer in building in custom format

conversion routines within an implementation project. The non-format dependent

element is included in the SAP standard system and includes database handling and the

transfer of data to Payment Engine.

Page 10 of 44


11/44

Typical access methods (feeder systems) to the Input Manager are:

Batch (using file management)

Document-based submission (such as files from optical character recognition)Submission by data medium (such as DME magnetic tape, disk)

Electronic Data Interchange (EDI) (such as banks, companies and private

customers using different access methods).

Automatically-generated payment orders such as securities settlements,

postings from other posting systems (loans or Account Management), scheduled

orders and so on

Standing order systems

Online

Self-service machines (such as ATMs, home banking – creation of orders

using the Internet).

Bank staff (such as counter staff, overdraft staff, Posting Control Office staff)

The customer format converter is identified in the File Handler using the channel,

medium and format. If the Input Manager is used, the customer format converter reads

the external data, converts this to Payment Engine metaformat and then transfers the

data to the non-format dependent element of the Input Manager, which then deals with

further processing. Further processing includes storing data that cannot be saved directly

in the metaformat in the File Handler database and transferring the data in metaformat

to Payment Engine. This mean that all fields of the original payment order or payment

item that are not required for processing in Payment Engine can be stored in the File

Handler database. The user can display any information stored on a payment order or

payment item in the File Handler database using payment order management. The data

is stored in the File Handler database under the same reference as in Payment Engine.

Page 11 of 44


12/44

Figure 5: Displaying File Handler Data in Payment Order Management

The original data from the File Handler database is still available to the Output

Manager during outgoing processing.

The following figure shows the important points of format conversion logic and

responsibility in inbound and outbound processing.

Page 12 of 44


13/44

File Handler

FileHandlerDatabase

Non SAP component

SAP component

Input Manager

Uploadto

Payment

Engine

Download

from

Payment

Engine

Output Manager PE - Felder

Customer formatconverter Original format

PE Metaformat

D M E

M T 1 0 3

E D I

M T 2 0 2

I n t e r n a l 1

I n t e r n a l 2

. . .

. . .

. . .

. . .

DME

File

Customer format

converter PE Metaformat Traget format

PO in PE

Metaformat

PE - Felder

F e e d e r a n d F o r w a r d i n g

S y s t e m s

M T 1 0 3

D M E

E D I

T A R G E T

I n t e r n a l 1

I n t e r n a l 2

. . .

. . .

. . .

. . .

Target

Format

PO in PE

Metaformat

Addit.

Fields

from

original

format

Processing

Figure 6: Data Flow Diagram (Using Batch Processing as an Example)

The Payment Engine provides a batch interface for individual and collective paymentorders. The batch interface can process files, the possible file size being dependent on

how the system is set up. For batch and online processing, the input format must be

converted to Payment Engine metaformat in the customer format converter or in an

feeder system. The system uses synchronous processing in the online interface and

issues a corresponding confirmation of the processing status. You can also supply

collective payment orders using the online interface.

Page 13 of 44


14/44

®

3.2 PAYMENT PROCESSING

Figure 7: Integration of Payment Processing in the Overall Process

Payment Processing manages payment orders and payment items, including necessary

status management. The Input Manager splits the information for an incoming payment

order into the elements of the metaformat:

Data for further processing (actual payment order including payment items)

Additional information such as remittance data

Only the actual payment order is used when processing in Payment Processing. The

additional information is stored in a database and a reference to it created in the payment order or payment item. When you create payment orders or payment items,

internal references are assigned in Payment Engine (such as payment order number,

payment item number, clearing area).

In addition, the system makes the relevant formal checks for payment orders and

payment items here.

Example checks on payment order level :

Duplicate processing, blank check form, recalls, payment order type, required fields,

priority, debit/credit check, and so on.

Page 14 of 44


15/44

Example checks on payment item level :

Transaction currency, transaction amount, account details, reference account details,

transaction type and its attributes, clearing area, payment item priority, required fields,recalls, and so on.

Customer-specific checks can be integrated using an SAP enhancement technique

(BAdI). Checks with errors result in the payment item or payment order being placed in

exception control.

Material checks (such as checking the account limit) are made in each account-

managing system and therefore depend on the functions provided in each system.

The Payment Engine provides functions for parking scheduled payment orders. You can

specify your own future execution date and time for payment orders. The payment orderis then parked until this execution date and time.

Payment order management allows you to search and display payment orders and items

flexibly. The user can always see the current processing status.

Page 15 of 44


16/44

®

3.3 ROUTE PROCESSING

Figure 8: Integration of Route Processing in the Overall Process

In Route Processing, a route, a clearing agreement and a value date agreement are

determined for each payment item.

3.3.1 ROUTE

The route serves to “roughly” classify payment items. Among other things, it

determines whether a payment item is internal (for a connected account-managing

system) or external. Some transfer parameters can also be stored (such as next clearing bank, value date rule set).

You can also set a lock for outgoing processing in the route. You could use this, for

example, if a transfer system cannot be used at a certain time due to technical problems.

The result is that temporarily Payment Engine does not generate any outgoing payment

orders for this route.

You can also deactivate a route during processing and thereby access Route Processing

quickly.

Page 16 of 44


17/44

Figure 9: Route Maintenance in Payment Engine (Basic Data Area)

Firstly, a unique route is determined for each payment item by means of a rule set.

There is a flexible selection of attributes available for this rule set (to determine the

route). All fields from the payment order or payment item from the metaformat

definition can be used as attributes. In addition, characteristics are provided which you

can use to restrict the validity time of a rule (for example, by date, time of day,

weekday, first/last day of the month). You can also integrate your own customer fields.

Figure 10 shows the logic for determining the route:

Page 17 of 44


18/44

Rule Bank Key Currency Transaction

Type

Priority Route

1 26661912 * * * INTERNAL

2 * EUR * 01 R1

3 ????4??? EUR

USD

1000-2000 * R2

4 * * * * R3

A payment item is specified with§ Bank Key 12244444

§ Currency EUR§ Transaction Type 1590

§ Priority 02

Using the above rule set, this payment item is processed as follows:- Check rule 1: Bank key does not match Check next rule

- Check rule 2: Currency matches, priority does not match Check next rule- Check rule 3: All criteria met Route R2 found

Figure 10: Simplified Example of Route Determination

3.3.2 CLEARING AGREEMENT

The conditions for transferring payment orders between banks are stored in the clearing

agreement. The following information is stored here:

Whether payment items are transferred individually or collectively

How the payment information is exchanged (directly or indirectly)

How the transaction value is provided

On which account settlement is made

Some transfer systems can transfer payment orders up to a certain amount only. Youcan specify a maximum amount in outbound processing for outgoing payment orders in

the clearing agreement. This means that the total of the order side of an order should not

exceed the amount specified there. You can also specify whether items are also to be

split if necessary.

Page 18 of 44


19/44

Figure 11: Clearing Agreement Maintenance in Payment Engine (Basic Data Area)

The rules for determining the clearing agreement can be set up flexibly in the same way

as for determining the routes. The route and clearing agreement are interdependent, in

that the route is determined first and then the clearing agreement within this route.

Figure 12 shows information on collective processing, which you can maintain in the

clearing agreement.

Page 19 of 44


20/44

Figure 12: Clearing Agreement Maintenance (Collective Processing Area)

3.3.3 CUSTOMER AGREEMENT

The customer agreement is a special agreement with a customer of the bank. It is a

record of internal clearing agreements including an associated rule set. There are

individual and general customer agreements. General customer agreements can be

assigned to several customers, whereas individual customer agreements can only be

assigned to one customer. You can, for example, store a collective option in a customer

agreement, which means that internal items are not posted individually to a recipient

account, but as a total.

3.3.4 VALUE DATE AGREEMENTThe Payment Engine also provides functions for determining the value date. The aim of

value date determination is to assign value dates to the payment items which require

them. The Payment Engine provides its own value date function for transferring

external payment items and setting up special value date rules (such as value split).

Value dating can depend on various parameters such as transaction type, amount and

currency. The actual procedure for calculating a value date for a payment item is stored

in a value date agreement. The value date agreement contains the following

information:

Whether a value date is necessary

Accept fixed value dates (default value dates)

Page 20 of 44


21/44

Use calculation formulas based on posting date

Use calculation formulas based on default value date

Use calculation formulas based on recipient item value date

You can also carry out a value split for ordering party items . A value split means thatseveral ordering party items with corresponding value dates are created from one

collective payment order, depending on the value dates of the recipient items.

Figure 13: Maintenance of Value Date Agreement (Calculation Data Area)

Determination of the value date agreement offers the same flexibility as route and

clearing agreement determination. Each value date agreement is assigned to a value date

rule set. Value date rule sets consist of rules that determine which value date agreement

is relevant for a particular item. Which value date rule set is relevant for a payment item

is stored in the associated clearing agreement or route.

Page 21 of 44


22/44

3.4 CLEARING AND SETTLEMENT

Figure 14: Integration of Clearing and Settlement in the Overall Process

Payment items are processed further in Clearing and Settlement. Depending on the

information provided by Route Processing (route and clearing agreement), and the

characteristics of the payment items to be posted, either a single posting is made

internally in the account-managing system (for example, SAP Account Management),

or a collector is generated. For an external payment item (such as express order), the

payment item can be transferred directly to the Output Manager in a new outgoing

individual payment order. If the payment items are to be collected as per the clearing

agreement, a clearing collector is opened and the payment items are placed there.

3.4.1 COLLECTOR

If payment items are to be placed into a collector and no open collector is available, a

new collector is created and the payment items are placed there. For collectors and

queues to be created, you can specify whether payment items with different

characteristics (such as different currencies or value dates) are assigned to one or more

collectors/queues.

Page 22 of 44


23/44

Clearing

Agreement

Collector

Characteristics

Collected

Items

Clearing

Agreement

Collector

Categories

Collector

Figure 15: Clearing – Processing Collectors (Basic Data Area)

When closing a collector, a collective payment order (including new ordering partyitem) and a clearing item are generated from the payment items in the collector.

Payment items refer to the relevant collector. The referencing to the incoming or

outgoing payment order and collector guarantees complete documentation. Collectors

can be closed automatically (using the closing criteria stored in the clearing agreement)

or manually. There are the following automatic collector closing criteria:

Reaching the pre-defined maximum collector total

Reaching the pre-defined maximum number of items

Reaching a pre-defined time together with a minimum total and

a minimum number of items in the collector (the conditions are linked with “AND”)

After the collector is closed, the clearing item (total of all individual items) istransferred to the account-managing system for posting. The collective payment order

generated is transferred to the Output Manager.

Further processing depends on each clearing scenario, described later.

Payment items for internal customer accounts can be placed in a customer collector. The

payment items in customer collectors are posted in total in the account-managing

system. A payment advice note on the payment items grouped together in this posting is

generated and transferred to the Output Manager for forwarding.

Page 23 of 44


24/44


25/44

Figure 16: Clearing – Process Queue

Page 25 of 44


26/44

®

3.5 FILE HANDLER – OUTPUT MANAGER

Figure 17: Integration of File Handler (Output Manager) in the Overall Process

The customer format converter in the Output Manager creates the specific format for

the outgoing payment order, based on the outgoing payment order from Payment

Engine and the additional original data from the File Handler database. The converter

can call the relevant transfer system, such as a file manager or a middleware.

Page 26 of 44


27/44

®

3.6 EXCEPTION CONTROL AND POSTPROCESSING IN THE

PAYMENT ENGINE

Figure 18: Integration of Exception Control in the Overall Process

The overall process of payment order processing is divided into a logical sequence of

processing steps and checks within Payment Engine. If there are any errors found in this

process that would prevent further processing of payment orders or payment items, then

a suitable response is required. Therefore, Payment Engine provides flexible functions

for exception control and postprocessing, thus enabling you to configure the control

over the possible system responses to errors that occur during payment order

processing. Exception control uses freely-definable rules to decide when a check result

leads to termination of processing and whether follow-up actions need to be carried out

on the object.

Determination of the relevant system response type depends on various parameters:

Process (such as incoming or outgoing payment orders)

Object category (such as payment order, ordering party item, recipient item)

Check phase (such as formal check, preparation for posting, posting in account-

managing system)

Check with errors

Characteristics of payment order or payment item

Page 27 of 44


28/44

The response types are generalized into response categories. The Payment Engine provides the following response categories:

Rejection/ Reversal: - processing of the payment order is stopped

- the payment order is rejected or reversed, depending on the processing status

For example: A payment order is rejected due to insufficient funds.

Postprocessing:- manual changes to the payment order or payment item can be made in accordance with

field selection control

- automatic resubmission function and determination of a final response if the

processing period is exceeded

For example: A payment item is rejected due to a formal error in the account-managing

system and needs to be manually postprocessed in Payment Engine.

Return:- processing of the payment item is stopped

- a corresponding posting is made to the ordering party

For example: The recipient account does not exist.

Redirection:- redirection of the payment item to a different internal account using an account symbol

For example: An account is closed. The payment item can be redirected to a new

account.

Further processing:- the check with errors is disregarded

For example: Disregarding the duplicate processing check for a particular feeder

system that always supplies the same type of payment orders.

The plausibilities in the rule set, that is, which responses are useful for which

combination of input parameters, are created depending on the process in question,

object category and check phase. You can set any permitted responses depending on

these parameters.

Page 28 of 44


29/44

Figure 19: Exception Control in Payment Engine

In exception control, you can control the rules for determining a response type. If youdo not want to differentiate the response type assignment, you can specify a standard

response type. This standard response type is a general response for each process, object

category and check phase in exception control. A rule set is used to find a differentiated

response type (see Route Processing).

Postprocessing is based on Payment Engine metaformat. In postprocessing, variousfunctions are available for payment orders (such as rejection, reversal) and payment

items (such as return, redirection).

Page 29 of 44


30/44

Figure 20: Processing Payment Orders (Exceptions for Payment Item Area)

Page 30 of 44


31/44

4 PAYMENT ENGINE - CHARACTERISTICS

4.1 MULTI-CLIENT CAPABILITY

The mapping of different business models, whether in the form of an IT center or

transaction bank, requires a certain amount of flexibility from the payment transaction

system for mapping existing organizational units.

Client capability in Payment Engine consists of the general definition of organizational

units (such as several legally independent banks) and the possibility of grouping these

together under a higher-level unit (SAP client), or mapping an independent unit as a

client in itself. Regardless of the type of mapping selected, each bank receives its ownset of control data and Customizing data for individual process control .

XX1 XX2 Bank07SAP Systems

001Client

PE Clearing Area

Bank05 Bank06

Bank01 Bank02 Bank03 Bank04

002

Payment Engine

Each client becomes:

• an own set of processing and master data (e.g. Routes)

• an own set of customizing for the individual process control

• an own authorisation set-up

Figure 21: Payment Engine – Multi-Client Environment

Figure 21 shows possibilities for the mapping of different business models. A client

represents a complete unit with regard to organization, commercial law and system

settings. One or more clearing areas are organizational units within a client. In this way,for example, special clearing scenarios between banks within a group can be processed

more quickly and efficiently.

Page 31 of 44


32/44

4.2 NON-FORMAT DEPENDENT PROCESSING OF DOMESTIC

AND FOREIGN PAYMENT TRANSACTIONS

For a standard processing logic within Payment Engine, SAP has implemented a non-

format dependent payment order for general use (Payment Engine metaformat). This

allows both domestic and foreign payment transactions to be processed in one

application.

Payment orders can be supplied or transferred as individual or collective payment

orders. A payment order is used to create a payment transaction and usually comprises

an ordering party item and one or more recipient items.

Payment Order Header

Individual Payment Order

Payment Order Header

Collective Payment Order

……

Ordering Party Item Recipient Item

Recipient Item 1

Recipient Item 2

Recipient Item 3

Recipient Item 4

Ordering Party Item

Figure 22: Payment Orders in Payment Engine

A payment order generally constitutes a set of payment items. Items can belong todifferent payment item categories: Ordering party item

Recipient item

Clearing item

Turnover item

Customers can define their own payment order types in the Customizing settings. These

specify process control characteristics such as checks to be made and a relevant field

selection control.

Page 32 of 44


33/44

4.3 TRANSPARENCY

The status concept allows you to see the current processing status of a payment order or payment item in the sub-components of Payment Engine and the account-managing

system at any time, and the processing history. This enables integrated monitoring of

the whole life cycle of a payment order . All user-initiated changes to an object, such as payment order, payment item, route, clearing agreement and so on, are logged in

Payment Engine in compliance with auditing requirements.

Application logs provide a function for monitoring the overall process flow in Payment

Engine. The aim of application logs is to make access to log data as simple as possible,so that the user can see what has happened to the relevant object.

Figure 23: Example Application Log

Page 33 of 44


34/44

4.4 PERFORMANCE

The Payment Engine stores all data in a relational database as a persistency mechanism. Performance-critical processing always takes place in batches using bufferingtechniques on both database and application levels. Processing in batches and bufferingtechniques greatly optimize the number of database operations.

The SAP NetWeaver technology platform offers flexible scalability of system

resources. The Payment Engine also enables mass processing by processing critical processes, such as payment order and collector processing, in parallel.

The Payment Engine is capable of managing the performance requirements of large

banks, IT centers and transaction banks.

4.5 MIGRATION STRATEGY

The generic architecture with clearly-defined interfaces to upstream and transfer

systems enables the gradual replacement of different existing payment transaction

applications. This means a reduced risk during implementation.

Page 34 of 44


35/44

5 PAYMENT ENGINE – OTHER FUNCTIONS

5.1 CLEARING SCENARIOS

Clearing in Payment Engine means the settlement and exchange of payment orders

between banks. The clearing scenarios describe the following aspects: How are payment orders exchanged?

How is the transaction value settled?

The Payment Engine can handle all known clearing scenarios. This includes: Direct clearing

Clearing using a clearing house (usually state central bank, correspondence bank

abroad),

Clearing with separate provision of cover

Together with the option of collecting payment items and the flexible definition of

criteria for closing collectors, clearing collectors can be generated in accordance with

specific clearing agreements.

Figure 24 shows an overview of the possible clearing scenarios.

Clearing Scenario

Direct Clearing Individual payment order/collective payment order - transport

without clearing house

Payment orders are exchanged directly

Uses direct account details (loro / nostro account)

Clearing through Clearing House Individual payment order/collective payment order - transport

with clearing house

Payment orders and clearing items are exchanged through a

clearing house

Clearing with Separate Provision of

CoverIndividual payment order/collective payment order - transport

with separate provision of cover through clearing house

Payment orders are exchanged directly

Clearing through clearing house

Figure 24: Overview of Clearing Scenarios

Page 35 of 44


36/44

®

5.2 CURRENCY EXCHANGE

Where the transaction currency of a payment item is not the account currency, the

automatic currency exchange function converts this to the account currency. Theamount in account currency is posted and information on the transaction currency and

exchange rate used for conversion is also transferred. Currency exchange items are alsogenerated for the correct balancing of currency positions. These currency exchange

items can be transferred to a connected account-managing system or foreign exchange

system.

-1995 USD to 30001005

+1995 USD to 10000001

Payment Order (PO1)

USDAccount

EUR

Account

1

Currency Exchange Function

Bank Clearing Account : - 1995 USD

Customer Account 10000001 : + 1995 USD / +2,122.34 EUR

Payment Order (PO1)

2

Currency Exchange Balance Sheet

Account EUR

Currency Exchange Balance SheetAccount USD

3

Example

Transfer to Bank of America customer account 10000001 for 1995 USD

Account currency of customer account 10000001 is EUR, 1995 USD converted to 2,122.34

EUR

Figure 25: Example of Currency Exchange

Page 36 of 44


37/44

5.3 END-OF-DAY PROCESSING

As part of end-of-day processing, you can schedule and execute different tasks as partof a job chain (for example, set Payment Engine reconciliation date, accrual run, or

reconciliation logs).

Example process flow for end-of-day processing: Increase reconciliation date in Payment Engine

Process all payment orders with the old date

Final processing of all open collectors and queues

Accrual

Send information on the new reconciliation date in Payment Engine to all account-

managing systems

Wait for processing of outstanding activities in the account-managing systems thatcould still generate orders with the old Payment Engine reconciliation date (such as

orders from interest settlements, cash concentration, and so on)

Final processing of all new open collectors and queues

Send information on the end of end-of-day processing in Payment Engine to all

account-managing systems

Increase the reconciliation settlement date in Payment Engine

5.3.1 ACCRUAL

For accounting in accordance with the regulations, business transactions must be created

correctly, completely and timely, and must allow tracking of their origin and processing .

The accrual function in Payment Engine determines which payment items belonging to

a payment order have only been processed on one side.

An accrual order is generated in Payment Engine that includes accrual items that can be

transferred to the account-managing system and to the general ledger during general

ledger transfer. Any outstanding postings (such as postings that have not yet been

entered on a recipient account) are posted to an accrual account in the account-

management system, and then taken off the books on the next posting day.

The following payment items are considered relevant for accrual:

Payment items in queues: A queue is kept open during end-of-day processing Payment items in collectors: A collector is kept open during end-of-day processing

Payment items in Payment Engine postprocessing: Payment items remain in PE

postprocessing during end-of-day processing

Page 37 of 44


38/44

PE Reconciliation Date + Posting Date in AMS

05/26/2003

Open Queue

25 EUR / C

(05/26/2003)

50 EUR / C

(05/26/2003)

100 EUR / C

(05/26/2003)

125 EUR / C

(05/26/2003)

Posting date ofaccrued

Items updated

Open Queue

50 EUR / C

(05/27/2003)

125 EUR / C

(05/27/2003)

25 EUR / C

(05/27/2003)

100 EUR / C

(05/27/2003)

Account-Managing System

300 (05/26/2003)

300 (05/27/2003)

Accruals Accounts

End-of-Day Processing:

Accrual ordercreated and processed in PE ->

items posted to accruals accounts

Account-Managing System

25 (05/27/2003)

50 (05/27/2003)

100 (05/27/2003)

125 (05/27/2003)

Customer Accounts

Items in queue are postedin

account-managing system

PE Reconciliation Date + Posting Date in AMS

05/27/2003

End-of-Day Processing:

Central date increased in systems

Figure 26: Description of Accrual Process

5.3.2 RECONCILIATION

Feeder systems deliver payment orders and payment items to Payment Engine for processing and transfer to the relevant following external or internal systems.

The following logs are used as proof of completeness of payment order processing:

Reconciliation log – feeder system

Reconciliation log – transfer system

Reconciliation log – account-managing system

Credit/debit equality check (total of credits = total of debits)

In addition to the reconciliation function, Payment Engine provides information on the

current status.

Page 38 of 44


39/44

Figure 27: Reconciliation Evaluation of Incoming Items (Feeder system Input Area)

5.4 AUTHORIZATION CONCEPT

Several roles can be assigned to an employee. Each role consists of one or moretransactions. The authorizations are attached to the relevant transaction. This enablesflexible control over authorizations. The authorization concept completes the client-capability.

5.5 RECALLS

The Payment Engine provides functions for handling recalls. The following recallcategories exist:

Payment order

For example: A complete payment order is recalled.

Recipient item

For example: A recipient item within a collective payment order is recalled.

Recipient item (decrease in amount) For example: A partial amount of a recipient item is recalled.

Recipient item (only final beneficiary bank)

For example: The processing of the payment order has already been completed by the

original ordering bank.

Page 39 of 44


40/44

There is an online interface for entering recalls within Payment Engine.

Recalls can be created before creation of the associated payment order or afterwards. In both cases, the system runs through a different flow logic:

Once an incoming payment order is processed, the system searches for a

corresponding recall for this payment order.

If a user creates a recall in online mode, the payment orders and payment items

already created can be searched for the newly created recall.

Figure 28: Example of Recall Processing

5.6 RELEASE

Certain business-related transactions can result in a release. For auditing, it is necessaryfor certain transactions to always be checked and authorized by at least one other

employee. For this, a release function with connection to the workflow based on the principle of dual, treble or quadruple control is used.

The following shows some example release objects:

Payment orders

Payment items

Recalls

Routes and rules

Clearing agreements and rules

Page 40 of 44


41/44

Customer agreements and rules

Value date agreements and rules

Assignment of general customer agreements

Payment Order Remains im Status “In Processing”

Status “For Release”

Figure 29: Release of a payment order

5.7 CORRESPONDENCE

Correspondence is used to notify customers and to document business transactions

internally. The Payment Engine provides the following correspondence templates:

Payment order – confirmation of non-execution

Payment order – confirmation of execution

Payment order – confirmation of reversal

Payment order – confirmation of partial reversal

Payment item – confirmation of return

Creation of correspondence is event-controlled. You can define your own layouts and

connect your own print procedures.

Page 41 of 44


42/44

6 SUMMARY

With Payment Engine, SAP is facing the challenges of forward-looking, efficient

payment transactions. Take advantage of the flexibility and many benefits the SAP

Payment Engine offers:

THE BENEFITS AT A GLANCE

• An integrated solution for all core processes for domestic and foreign payment

transactions

• Format-neutral, standard processing• Multi-Client capability

• Supports new business models (such as transaction banks)

• Integrated exception control and postprocessing functions

• High level of performance

• Customer-specific enhancements can be implemented without changing the standard

development

• Preparation for intraday interest calculation

• Open integration platform for payments and postings between different position-

managing systems

•

Supports “Straight Through Processing” (STP)• High level of integration and clear interfaces, low implementation expense in Core

Banking

• Reduction in processing costs through synergies when using several SAP

components

• High level of automation in payment transaction processing • 24-7 real-time processing

Page 42 of 44


43/44

7 THE WAY AHEAD

We plan to implement future enhancements to the existing functions based on new

requirements, in particular foreign payment transactions. The implementation and

priority of these requirements depends on the requirements of pilot customers. Thefollowing describes some planned functions for which conception and design is already

underway.

Receipt of Coverage Match

In the clearing scenario “Individual Payment Order or Collective Payment Order with

Separate Provision of Cover”, a bank forwards payment orders directly to the recipient

bank. The value-based clearing is separated from the directly-exchanged payment orderand is carried out by the relevant clearing house. The credit is only made to the recipientaccount at the recipient bank after a successful credit to the clearing house, where an

immediate credit (before the actual clearing) is also used. The following functions,among others, need to be considered when implementing this process:

Management of receipt of coverage (create, display, change, delete, release)

Automatic matching of receipt of coverage:

The automatic matching of payment information and receipt of coverage assumes that

clear matching criteria exist. For example, this can take place using a unique reference

number.

Manual matching of receipt of coverage:

In management of receipt of coverage, the receipt of coverage can be compared with the payment information and processing staff can use this to make a manual match.

Individual transactions can be matched.

Acceptance Agreement

We also plan functional enhancements with regard to maintenance of acceptance

agreements. In an acceptance agreement, you can store various kinds of information on

the acceptance and processing of payment orders. For example, the following

information can be referred to: permitted payment order types (currencies/amount

limits/authorization procedures), whether recalls are permitted, charges information

(such as BIF/MIF rules), request for cancellation, and so on.

Calculation of Charges

As with customer agreements, there are also fixed agreements between banks as to

which type, limit and form of payment orders are accepted and cleared. In bilateral bank

relationships, STP approaches play a major role and have a lasting influence on the

charges framework . The implementation of a standardized bilateral or multilateralcharges policy (see BIF and MIF) brings with it the possibility of automation of the

charges process. In the case of a payment for which the ordering party pays the whole

costs (OUR), the transaction costs of the recipient bank must be determined and

transferred to the recipient bank together with the payment data including details of the

cost. We plan a function which can be used to determine inter-bank fees for Payment

Page 43 of 44


44/44

Engine. After the inter-bank fee is determined, the corresponding order is adjusted

(amount change). The amount can thus be posted or forwarded.

Currency Exchange

We also plan functional enhancements with regard to currency conversion, such as the

call-up of a customer-specific component for determining the exchange rate or for

currency exchange.

We also plan interfaces to neighboring systems. For example:

Regulatory Reporting Component:

In foreign payment transactions, the regulatory reporting rules of the foreign trade

regulations must be observed. Each country has different requirements for the

regulatory reporting function and these are therefore not provided in Payment Engine.

The Payment Engine can, however, support regulatory reporting by providing allexisting and relevant data stored in Payment Engine to the regulatory reporting

application using an interface.

Liquidity Management

Liquidity management is also gaining importance in banks. However, the data used for

this, and how it is formatted, varies greatly. The customer’s own liquidity management

system for liquidity control can be provided with the information relevant for posting

from Payment Engine using an interface.

Nostro Account Reconciliation

The reconciliation of nostro accounts based on incoming (electronic) bank statements is

either done directly in the relevant account-managing system or in a separate

application. The Payment Engine supplies all information relevant for posting using an

interface.

The Payment Engine will provide an archiving function for transaction data.

04 workingpaper paymentengine english

Documents