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.
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:
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.
– 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
- 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.
Standard mappings are used for FIN and FTA payments as shown in below
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
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 formapping 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
- 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
Great blog, Vimal 🙂 !!
Thanks a lot Akshay!!!
Thank you so much for this document. It is very helpful. But I would like to know if you ever had a chance to work on FTP connection on bank and if yes, how did you included those additional tags for automatic connection purpose at the header level in the DMEE where the expectation is to have multiple tags at the same level at the header?
Thanks for this detailed documentation. I would like to know if you did get a chance to work on FTP connection. If yes, Can you tell me how did you included those requisite tags to the header? Because the bank is requiring three tags to be added at the same level at the header which system is allowing us to do so. Can you shed some light on this?
Thanks for the document...Appreciated!!
I am also in the implementation phase of SWIFT in which I am getting a FileAct file in source side from BCM which contains the overrides(for the parameter file) and the payload data. I am using the mapping SWIFT_payloaf_parFile_split and so the .xml and .par file is getting created in the target folder. The .xml file is the same as the input file with all the overrides and other payment data and the .par file is having algorithm and value.
Is this correct.
I am using the adapter module localejbs/swift/FileActConversionToSWIFTModule and has set the parameters - DetachParameters to true, UseLocalSecurity to true and KeyId - the one maintained in the key manager. These are set in all the three channels(one sender and 2 receiver).
Kindly Validate am I following the correct process.
Also I am facing the issue like if the input file name is SEPA.xml then the payload file gets created with the name SEPA.xml and the par file with the name SEPA.xml.par but I need only SEPA.par. How this can be achieved. I have used ASMA and ticked the FileName and FileType.
Yes from the above explanation you are going the right way, though you need to test it thoroughly with the BCM tools and SwiftNet at security level.
For achieving SEPA.par file name instead of SEPA.xml.par try using a logic to retrieve the filename using Dynamic Configuration and then changing it using a UDF. Alternately you can try using variable substitution.
Now I am able to generate the payload and parameter files perfectly. There were some problems in the input file.
I will try dynamic configuration for the File name.
Great post and good summery of how to use BCM.
Thanks a lot!!!
Please look into the below post, if you can help me on this.
Swift Integration Package to split payload and .parfile
Great job Vimal..Amazing way to demonstrate BCM interface implementation in PI!!!
Thanks a lot!!
Great blog with complete information. Thanks for sharing.
Nice Blog Vimal... very descriptive 🙂 !
Excellent and very useful document.
Good blog Vimal, very detailed!!!!!!!
Excellent article. I have one follow up question. You have mentioned that after the collective payment run a single file is created which is then encrypted in BCM module.
Can you provide some more information on how is the encryption of file enabled / setup in BCM prior to the file transmission to PI.
The File gets encrypted when the same is created by the BCM module. Once the Payment is submitted using the BCM in SAP ECC system a Batch job is triggered which creates the File in encrypted way. This file is then picked by SAP PI from AL11 of ECC system.
Thanks so much for the input. Is there any additional configuration / code enhancement in the BCM module to enable encryption when the file is created. Reason I ask this question is because I have heard from some folks that there is no encryption capabilities in SAP BCM so am trying to confirm if the reason people are saying this is because they are not aware of how encryption is enabled. Any additional information you can share on how to enable encryption in BCM would be appreciated.
Firstly, this is really a very nice blog on BCM.
I see the datatype of the structure used in PI consists of many different fields. But the file given by my BCM consultant it is just a MT100 file. Hence i wanted to know, how the MT100 file gets converted into this datatype structure?
I am currently stuck up on this. Any help on this will be highly appreciated.
Hi - On figure 6, what is the 'SWIFTNet Interface' component depicted? Is this component internal within the enterprise?
(I am not sure if say SWIFT Alliance Lite II is required to connect PO to SWIFTNet)
Thanks in advance
In Sender Communication channel we are just checking the whether Digitally signed or not.
1. If it was signed then we need to use that Key?
2. from SAP where we get that digital signature key?
3. Where in sender communication channel we have to use that Key?
Great blog Vimal. It helped me a lot.
I have a question.....
Did you use SFTP on the receiver channel as well? In my case, I have one sender and two receiver channels (To send one Par file one Payment file) and I am planning to use FTP on the sender and SFTP on the receiver channels. Is that possible? Also, do I need to add the SwiftConversion modules on all three receivers?
Many thanks for you help.
In Figure.13, is that the signature or the encrypted message? Also, why does the Payload and PAR file tags have the same value?
Hi Vimal ,
We have a requirement to Format and undergo Data conversions with Bank statement mt940/42. Will the FIN/FileAct conversion module help me to convert the files to XML format.
We are currently using SWIFT 622 . Currently we are just Picking the file and placing it in the Output server using dummy mapping .
Let me know if BCM SWIFT package has any adapter modules for Bank statement formats to XML.
Is there any limitations in field values?
Hi, thanks for your sharing, it's really usefull for us. I have the same integration scenario, and i have more detail information need to know from you. how can i contact with you? could you share me your email address, then i can contact with you by email. Thanks a lot.
Thanks for the document. I am getting BCMSigned files from ECC and then I am using split_par_payload to generate 1 file. However, when I check source file it looks like
Source file -->
PI File -->
Target location -->
its pain XML structure payload file....
I understand how BCMSigned getting generated from ECC, then PI sender adapter is responsible for converting it to payload and parFile.
I am not getting how these files getting converted into pain files at target folder location. Please help to understand.
We basically dump these encrypted files to the Target Location and there the Third Party system takes care of reading these file using Encryption Algorithms (Probably the Swift System). They then forward to the Banks for further processing.
We are only responsible to transfer these files using the Swift Algorithm for Encryption (Triple DES or something, Dont remember it today) and also the keys which allow the SFTP transfer.
I read your blog and the following are my questions.
You stated that you use swift id to verify the bcm encryption at the PO system level for international payments. In that case, did you use pgp at the receiver side or not?
For both domestic and foreign payments, do you use the same sender and receiver channels?
Can standard payroll files be processed from BCM to Swift?
I value your response.