A Construction Group Automated SAP-to-Bank PGP Payments Without Changing SAP or Its Banks

A Latin American construction and industrial group builds large infrastructure across its region: roads, bridges, airports, and transit. It also manufactures much of what goes into that work, through a materials division that supplies its own projects and exports.

An operation of that scope moves a constant stream of money through its banks. Two to three times a day, SAP generates a batch of XML payment files that have to reach the group's banks: signed and encrypted with PGP under each bank's key requirements, delivered to the bank's own SFTP server, and matched later against an encrypted response file that records which payments were accepted, which were rejected, and why. That exchange is where the group's money actually moves. And every step of it was performed by hand because SAP's file-based process and the banks' SFTP and PGP requirements were fixed endpoints the group had to bridge.

A Payment Cycle Run by Hand, Two to Three Times a Day

Each of those two or three daily runs was a hand-driven routine from start to finish.

SAP wrote the payment files into a folder on an on-premises server. An operator picked them up, signed each one and encrypted it with the bank's public key in a desktop GPG tool, then opened FileZilla, connected to the bank's SFTP server, and uploaded the files by hand. Then came the wait. When the bank's response file appeared, the operator downloaded it, decrypted it, and placed it back on the server for SAP to read. That was one cycle.

The rest of the cycle was manual too. Response files were checked by hand, and a rejected payment was reprocessed by hand. The group wanted accounting to read payment status straight from the response files instead of asking the team that ran the transfer.

Neither SAP nor the Banks Were Going to Change

The cycle had survived because neither end of it could move. SAP integrated with the outside world through files: it wrote payments into a folder and read responses from one, and the group would not modify the ERP to change that. The banks dictated everything on their side: the SFTP endpoints, the PGP key requirements, the file formats. A mid-sized industrial group does not ask a global bank to change its process. So the gap between the two systems was closed the only way it could be closed at the start, by hand.

Then the load began to double. The group was standing up the same cycle with a second bank, which meant twice the manual runs. At the same time, accounting wanted direct access to the banks' response files.

What the fix had to do was clear. It had to reach a folder on an on-premises server, sign and encrypt every payment file with the right bank's key automatically, deliver it over SFTP to an endpoint the bank controlled, then pull the response back, decrypt it, and put it where SAP expected to find it. It had to keep an archive of everything that moved and give accounting a window into the results. And it had to do all of that without changing SAP and without asking either bank for anything.

The group selected Files.com to be that layer.

An Automated Layer Between SAP's Folder and the Banks' Servers

Files.com became the layer between an ERP the group would not modify and banks it could not: it watched SAP's folder, did the cryptography, carried the files, and kept the record.

The group's information security coordinator configured the whole workflow from the Files.com documentation. The group then ran it in parallel with the manual process, rolling it out one bank at a time.

A Files.com Agent ran inside the group's network, on the server where SAP wrote its files. The Agent connected outbound only, so the SAP file server was never exposed to the internet. It continuously synced the output folder into Files.com.

From there, folder-level GPG automatically signed and encrypted each payment file with the bank's public key, with the keys held in Files.com. Files.com Automations delivered the encrypted files to the banks' SFTP servers, connected as Remote Servers. On the return path, Files.com retrieved each bank's response, decrypted it, and delivered it to the on-premises folder where SAP read it.

Around the core flow sat the controls that come with running the cycle on a platform. Encrypted copies of every file were archived to Azure and S3 for history and compliance. Automations retried on failure. Files.com Expectations monitored the flows, so a response file that did not arrive on time was flagged. And accounting received folder-level read access to the in and out folders, where each bank's responses recorded whether a payment was accepted and, if not, why.

The Run Executes on Its Own, and Accounting Reads the Result

With the workflow in production, the group has replaced a hand-run payment cycle with a platform pattern that repeats on its own.

• The payment run executes two to three times a day with nobody performing it.
• Accounting reads payment status directly. The response folders show which payments were sent, which were accepted, and which were rejected and why.
• The second bank came online on the same encrypt, transfer, and decrypt template instead of doubling the manual burden. Adding another banking partner is the same pattern configured again, not a new manual routine.
• Every payment file and response is archived, encrypted, to Azure and S3, so the group holds its own record of everything exchanged with its banks.

The Pattern Replaced the Routine

Since the cutover, nothing at either endpoint has changed. SAP still writes its payment files into the same folder and reads responses from the same place. The banks still run the same SFTP servers and require the same keys. What changed is what sits between them: the signing, the encryption, the delivery, the return, and the record now belong to Files.com instead of to a manual routine.

The group automated an ERP-to-bank payment cycle end to end without modifying the ERP and without asking a bank to change anything, and the same template stands ready for the next banking partner. The information security team now supervises the run instead of performing it.