Grupo Estrella Automated SAP-to-Bank PGP Payments Without Changing SAP or Its Banks

Grupo Estrella is one of the principal construction and industrial groups in the Caribbean. From Santiago de los Caballeros in the Dominican Republic, it builds large infrastructure across the region: roads, bridges, airports, and the guideway of the Santiago monorail. It also manufactures much of what goes into that work. Its materials division produces cement, concrete, structural steel, and rebar, for its own projects and for export. Few contractors anywhere own their input chain so completely. The group employs roughly 6,000 people.

An operation that size 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 Grupo Estrella'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 Grupo Estrella had to bridge.

A Payment Cycle That Ran Through One Person, Two to Three Times a Day

If Daniel Cruz was away from his desk, Grupo Estrella's payments did not go out.

Cruz, the group's information security coordinator, was the payment run. SAP wrote the payment files into a folder on an on-premises server. He picked them up, signed each one and encrypted it with the bank's public key in the GPG for Windows interface, then opened FileZilla, connected to the bank's SFTP server, and uploaded the files by hand. Then he waited. When the bank's response file appeared, he downloaded it, decrypted it, and placed it back on the server for SAP to read. That was one cycle. There were two or three of them every working day.

“The biggest issue: we have to do it manually, and it depends on Daniel.”

The rest of the cycle was as fragile as its middle. Response files sometimes came back empty, misnamed, or missing, and had to be checked by hand. A rejected payment had to be reprocessed manually, because there was no retry. And the accounting team had no view into any of it: to learn whether a payment had been sent, accepted, or rejected, they asked Cruz.

“I tried to take a day off yesterday, but I couldn't.”

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 Grupo Estrella 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 a person.

Then the load began to double. Grupo Estrella was standing up the same cycle with a second bank, which meant twice the manual runs, still through the same hands. At the same time, accounting was asking for direct access to the bank's response files instead of routing every status question through one person.

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.

Grupo Estrella 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.

Cruz configured the whole workflow himself from the Files.com documentation. Grupo Estrella then ran it in parallel with the manual process, rolling it out one bank at a time.

A Files.com Agent ran inside Grupo Estrella'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 rather than on one workstation. 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 the manual process never had. Encrypted copies of every file were archived to Azure and S3 for history and compliance. Automations retried on failure instead of waiting for a person to notice. Files.com Expectations monitored the flows, so a response file that never arrived was flagged rather than discovered by hand. 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 Can Finally See It

With the workflow in production, Grupo Estrella 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. A day off no longer stops the group's payments.
• Accounting reads payment status directly. The response folders show which payments were sent, which were accepted, and which were rejected and why, with no question routed through one person.
• 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 job for a person.
• 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 Person

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 one person's working day.

Grupo Estrella 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 security coordinator who could not take a day off now supervises the run instead of performing it.

“I'm excited. I'm safe.”