Download - 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
-
8/18/2019 04 WorkingPaper PaymentEngine English
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
-
8/18/2019 04 WorkingPaper PaymentEngine English
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
-
8/18/2019 04 WorkingPaper PaymentEngine English
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
-
8/18/2019 04 WorkingPaper PaymentEngine English
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
-
8/18/2019 04 WorkingPaper PaymentEngine English
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
-
8/18/2019 04 WorkingPaper PaymentEngine English
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/18/2019 04 WorkingPaper PaymentEngine English
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
-
8/18/2019 04 WorkingPaper PaymentEngine English
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
-
8/18/2019 04 WorkingPaper PaymentEngine English
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
-
8/18/2019 04 WorkingPaper PaymentEngine English
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
-
8/18/2019 04 WorkingPaper PaymentEngine English
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
-
8/18/2019 04 WorkingPaper PaymentEngine English
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
-
8/18/2019 04 WorkingPaper PaymentEngine English
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
-
8/18/2019 04 WorkingPaper PaymentEngine English
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
-
8/18/2019 04 WorkingPaper PaymentEngine English
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
-
8/18/2019 04 WorkingPaper PaymentEngine English
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
-
8/18/2019 04 WorkingPaper PaymentEngine English
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
-
8/18/2019 04 WorkingPaper PaymentEngine English
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
-
8/18/2019 04 WorkingPaper PaymentEngine English
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
-
8/18/2019 04 WorkingPaper PaymentEngine English
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
-
8/18/2019 04 WorkingPaper PaymentEngine English
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
-
8/18/2019 04 WorkingPaper PaymentEngine English
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
-
8/18/2019 04 WorkingPaper PaymentEngine English
24/44
-
8/18/2019 04 WorkingPaper PaymentEngine English
25/44
Figure 16: Clearing – Process Queue
Page 25 of 44
-
8/18/2019 04 WorkingPaper PaymentEngine English
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
-
8/18/2019 04 WorkingPaper PaymentEngine English
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
-
8/18/2019 04 WorkingPaper PaymentEngine English
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
-
8/18/2019 04 WorkingPaper PaymentEngine English
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
-
8/18/2019 04 WorkingPaper PaymentEngine English
30/44
Figure 20: Processing Payment Orders (Exceptions for Payment Item Area)
Page 30 of 44
-
8/18/2019 04 WorkingPaper PaymentEngine English
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
-
8/18/2019 04 WorkingPaper PaymentEngine English
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
-
8/18/2019 04 WorkingPaper PaymentEngine English
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
-
8/18/2019 04 WorkingPaper PaymentEngine English
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
-
8/18/2019 04 WorkingPaper PaymentEngine English
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
-
8/18/2019 04 WorkingPaper PaymentEngine English
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
-
8/18/2019 04 WorkingPaper PaymentEngine English
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
-
8/18/2019 04 WorkingPaper PaymentEngine English
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
-
8/18/2019 04 WorkingPaper PaymentEngine English
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
-
8/18/2019 04 WorkingPaper PaymentEngine English
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
-
8/18/2019 04 WorkingPaper PaymentEngine English
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
-
8/18/2019 04 WorkingPaper PaymentEngine English
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
-
8/18/2019 04 WorkingPaper PaymentEngine English
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
-
8/18/2019 04 WorkingPaper PaymentEngine English
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.