Document Objective
The payments for different vendors submitted to different Banks need to be secure and should meet all the compliance agreed with the Bank and the Third Party service Provider. We therefore require a strong and secure mechanism that ensures the transactions are done in safe manner.
This interface is used to send payment files from ERP via PI and the SwiftNet network to the banks. We will use the standard ‘SAP Integration Package for SWIFT 6.22’ which contains the required interface to make the integration happen. In order to make sure the contents of the file are not visible to anyone, we will encrypt the file. As the communication between ERP and PI is secured by Secure Socket Layer, no encryption is required when the file leaves SAP ERP. Encryption is needed when the file arrives in PI.
Why use BCM and SwiftNet for Payments?
BCM - The Bank Communication Management ES bundle supports the communication of financial transactions of a company to its banks via the Society for Worldwide Interbank Financial Telecommunication (SWIFT) network. It includes Enterprise Services for the creation and status tracking of payment orders as well as enterprise services for receiving bank statements.
SwiftNet - SWIFT operates a worldwide financial messaging network. Messages are securely and reliably exchanged between banks and other financial institutions. SWIFT also markets software and services to financial institutions, much of it for use on the SWIFT Net network.
Figure 1: Advantages and flow using BCM
The procedure and transactions at the backend system (ERP) are explained in brief and will not be covered as part of this document.
Document Detail
There are 2 major types of payments which are generated from ECC system. The classification of the payments are as under:
- FIN (Financial Institution Transfer) – International Cross- Border Payments
FIN message are used for Payments and cash management
- FTA (Federal Tax Application) – Domestic Payment within Country
The Federal Tax Application provides a same-day federal tax payment mechanism for business tax filers and payroll processors via their financial institutions.
The payments created in both the cases different. File format depends on type of payment and bank. Below are some of the examples:
Bank | Type | Service | Format |
Bank ABC | Cross-border | FIN | MT101 |
Bank ABC | Domestic | FileAct | XML |
The field mapping for MT101 is standard SAP and part of ERP. For XML, this is part of configuration through transaction DMEE1 also in ERP. No interpretation or conversion of the files by the interface is required.
The payment is generated with all the necessary conditions for the definite Bank and then sends for approval. After approval a batch job is run in ECC system to create collective payment in a single file. The file is then encrypted in BCM module.
The file is sent to respective folders in located in the ECC server. The details can be seen using T-Code AL11. There are different folders created for different Banks and in addition we also have archive folder which will be explained later.
Figure 2: Folder location for FIN(fin) and FTA(fileact) Payments in AL11
Figure 3: Different folders created for different Banks in AL11
After the Batch file is created the status of the batch can be seen in BNK_MONI. Below are the statuses of the payment file:
Figure 4: Display Batches created for payments
We can check the Status History for the Payment by selecting the Row and right click it:
Figure 5: Check Status of the payment
BCM & SwiftNet Integration with SAP PI
Files processed and sent by BCM via SAP PI are in standard format for SwiftNet to process them. We have not used any mappings to change the incoming file format. PI polls the files from AL11 directory of ECC system and sends the same file to Third Party system through SwiftNet Network. The Third Party is accountable for delivery of payments to Bank and receipt of Bank Statements from Bank. The flow Diagram is as under:
Figure 6: Flow diagram of Integration of SAP PI with BCM and SwiftNet
The standard SWIFT Product provided by SAP needs to be imported in ESR (Enterprise Service Repository) in SAP PI system. The standard formats for FIN and FTA are used from the SWIFT module under SWIFT 622:
Figure 7: Standard interfaces, mappings and Imported Archives from SWIFT Module
Encryption and Signature check
We have used SFTP Adpater (Adapter from Aedaptive version 3.0) to poll the files from ECC system. "SSH File Transfer Protocol" or SFTP is a network protocol that provides file transfer and manipulation functionality over any reliable data stream. It is typically used with the SSH-2 protocol to provide secure file transfer. SFTP encrypts the session, preventing the casual detection of username, password or anything that is being transmitted. One key benefit to SFTP is its ability to handle multiple secure file transfers over a single encrypted pipe. By using a single encrypted pipe, there are fewer holes in the corporate firewall.
Figure 8: SFTP Module Deployed in ESR
All the files created in AL11 folder of ECC system will contain a signature. The verification of the signature is done in PI system using the Module Key and parameter from SWIFT Module.
In order to show the Encrypted and signed file we have taken the below screen as there are no files currently in fileAct folder in ECC system.
Figure 9: Encrypted and signed file
Configuration in Integration Directory for Payments
Sender Channel configuration
We have used different channels for different Banks. This makes easy for supporting testing for Banks whenever required. Channels for the banks which are not in scope for testing will be switched off.
The signature is verified using the parameter “VerifyBackendSignature” available in the SWIFT Module as under:
Figure 10: Module Parameters used for integration with ECC
Details on Module Paramters at Sender:
- IsNotificationRequested – This parameter is marked ‘true’ to receive Notifications from Bank for the payments done.
- IsUrgent – The parameter is marked ‘false’ inorder to avoid the urgency.
- KeyId – This is the unique Key Id for every system integrated with SwiftNet in the Landscape. The value format is SWIFT_<SID>. SID – System ID of Development/Test/Production system
- UseLocalSecurity - Messages are securely and reliably exchanged between banks and other financial institutions
- VerifyBackendSignature – All incoming files from ECC will be checked if they are signed by BCM module. The unsinged files will not be processed and the channel will show error message in PI system.
- Exit is the standard module for in SFTP
Note: The signature verification at Sender is used for International Payments only. We have not used signature verification parameter for the Sender channel for Domestic Payments.
Masking of incoming files:
The Source Directory contains the location for the AL11 directory. File Name Scheme represents the nomenclature of the files to be picked from the folder of AL11. Advanced Source File Selection has also been done in order to not send unnecessary files to Bank and only process required payment file.
- Msecs to Wait Before Modification
Check where PI waits some time from first finding the file, until reading and processing it later, and the file is only processed if it had not changed over
the waiting period. As shown below PI waits 10 minutes until the file is complete - Masking – Suppose we want to process all files that have the extension '.nfs', but want to exclude all files that begin with the letter 'GB2'. To do this follow the below:
Figure 11: Channel configuration for polling payment files
Additionally mention the connection parameters like host name of the sending server, port, UserId and Password for Authentication. The UserId and Password should be maintained at the server Level and should not be a Dialog/System User.
We place the processed files in Archive folders in ECC system.
Receiver Channel Configuration:
The receiver channel will contain the Third Party information. We have used PGP (Pretty Good Privacy) Encryption also happens when the payment are sent from PI system
Figure 12: Encryption at Target
Details on Module Paramters at Receiver:
- armor - If the protocol (or) transmission channel supports only ASCII printable characters, the data to be transferred should be encoded as plain text. This is referred as binary to text encoding. If it is applied on the plain text itself, and decoded on the receiver end is called "ASCII Armoring". To turn on the value we input is “true”.
- encryptionAlgorithm – In cryptography, Triple DES is the common name for the Triple Data Encryption Algorithm (TDEA or Triple DEA) block cipher, which applies the Data Encryption Standard (DES) cipher algorithm three times to each data block.
- publicKeyRing
- The public key is used to code a digital message in order to make it unreadable without the use of a private key, which typically takes the form of
a password. - recipient – Target mail recipient ID.
Note: The signature verification at Receiver is used for Domestic Payments only. We have not used signature verification parameter for the International Payments at Receiver end.
Mappings:
FIN and FTA Mappings
Standard mappings are used for FIN and FTA payments as shown in below
figure:
Figure 13: Mapping for FTA Payments
Figure 14: Message Processing in PI
Figure 15: Mapping for FIN Payments
Bank Statements and Notifications from Banks/ Third Party System
As soon as the payment reaches the third Party system, that connects with different Banks, a technical acknowledgement is send back to PI system notifying the receipt of payments. These feedbacks files are sent by the Third Party for FTA and FIN Payments. In addition to these feedbacks, Banks sends a payment status notification PAIN back to SAP PI system after receiving the payment. The payment Status are sent to ECC system using Proxy and the status are changed accordingly in transaction BNK_MONI. We also receive notifications from Bank for FIN and FTA payments. These notifications have two different formats, namely TXT and XML file format. This will be discussed in next section.
Payment & Bank Statement Notifications
Payment Notification
The Payments sent to Third Party are acknowledged by the Third Party System and the Bank. As soon as the payment file reaches Third Party system a Technical Acknowledgement is send back to PI and the same is sent to ECC system. The status in ECC is updated in BNK_MONI (BCM Module Transaction) (Refer Figure: 5).
FIN & FTA Payment Acknowledgement by Third Party
- The acknowledgement is received from Third Party system when a FIN payment is received at Third Party. There is not encryption done for the acknowledgement process.
- The mappings used are from the standard Operation mapping SwiftFIN_PaymentStatus and SwiftFTA_PaymentStatus from the SWIFT Module. (Refer Figure: 7)
PAIN Acknowledgement by Bank
- The Acknowledgement sent by Bank to PI is in a different format and the same we refer as PAIN.
- No encryption or check done.
- The format for the file sent is a report which can be found in Software Component Version ISO20022 1.0 in namespace http://sap.com/xi/ISO20022
and report name as PaymentStatusReportV02. - This report is mapped to CollectivePaymentOrderNotificationMessage that is a structure from SAP APPL 6.04 in namespace http://sap.com/xi/APPL/Global2 .
Bank Statement Notifications
TXT Bank Statement Notification for FIN payments:
The statement is sent as a plain text file and the same is sent to ECC system in two different ways:
- The file is send to AL11 directory directly to keep a track of the Banks statements
- A service message is sent to ECC using SOAP.
There are no mapping used exclusively for the TXT formats, except the filename are fetched dynamically during runtime.
XML Bank Statement Notification for FTA payments:
The Notifications sent in XML format use the XSD format which we have received from Bank. We have also used the interface(BankAccountStatementNotification_In) and namespace http://sap.com/xi/APPL/SE/Global from ESA ECC-SE 604 Software Component for
mapping the required fields.
mapping the required fields.
Figure 16: Mappings for XML format
Issues and Resolution
# Duplicate Payments to Bank
- Duplicate payments are not processed at Third Party end that nullifies the risk.
# Payments sent to different Bank causing delay and inconsistency.
- The version of the SFTP adapter had a bug of routing the payments to incorrect channels leading to inconsistencies and escalations. A new version
was deployed that solved the issue.
# Issues with Public Key Ring in communication channel
- The Public Key for validating and handshake mechanism should be deployed at the server level in PI system. This Key is provided by Third Party.
# Status updated incorrectly in BNK_MONI in ECC
system
system
- Due to network issues between SAP PI and Third Party or Third Party and Bank, the status get incorrectly assigned in BNK_MONI. For eg: Accepted By Bank is sent before Received By Bank. Network checks required to be done during connectivity tests to ensure there are no delay
Feedback from Users using BCM and SwiftNet Integration with PI
- Lower TCO by becoming independent from proprietary payment standards and bank-specific e-banking products and setting up a single communication
channel to SWIFTNet, which will enable your company to communicate with all the banking partners through this one channel. - Minimize bank connections and enhance straight-through processing rates via end-to-end integration with SWIFTNet
- Full implementation of SAP Bank Communication Management application and SAP Integration Package for SWIFT is a SAP Ramp-Up program in less than 6 months