Files.com delivers payment files to every bank and processor encrypted with that counterparty’s key, on its cadence, from addresses it can whitelist, and brings the acknowledgements, settlement reports, and statements back before reconciliation starts. Treasury and accounts payable run every bank from one place.
Each bank dictates its own terms: SFTP, PGP under its key, a static IP, a daily cutoff. Today those terms are met by a person at a portal, a script per bank, or a server someone patches so that banks can connect to it.
A payment file is not like other files. The bank must have the ACH batch before a cutoff or nobody is paid. The positive-pay register must arrive or a forged check clears. The settlement file must come back or reconciliation waits. And every bank sets its own protocol, encryption key, whitelist, and clock.
Meeting those terms by hand or by script means the control rests on one person’s morning or one engineer’s memory. On Files.com the key is a folder setting, the cutoff is a schedule, the address is fixed, and the file that did not arrive is an alert rather than a discovery.
Real companies. Real file flows. Real results.
Outbound to the bank before the cutoff, inbound before reconciliation, and, at a bank, inbound from every business client.
The ERP writes the NACHA batch or wire file into a folder. Files.com encrypts it with the bank’s PGP key and delivers it to the bank’s SFTP endpoint on the schedule the cutoff demands, named the way the bank’s intake expects.
The check register goes to the bank in the order and format it requires, so a check the bank does not recognize is refused. A missed register is a fraud control switched off for a day; a scheduled delivery means it never is.
Files.com pulls the daily settlement report, lockbox receipts, and BAI statements from the bank’s or processor’s SFTP on their cadence, decrypts them, and lands them where reconciliation reads. The acknowledgement for this morning’s ACH batch comes back the same way.
A bank or payment platform gives each business client its own folder and credential on the bank’s own domain. Clients upload ACH and positive-pay files over SFTP or a browser, and the file is routed to the core processor or verification vendor on arrival.
Encryption by rule, each counterparty’s cadence unattended, addresses the bank can whitelist, and an alert for the file that did not come.
PGP is a folder setting: each bank’s public key encrypts everything dropped in that bank’s outbound folder, and your private key decrypts what comes back. Nobody in treasury runs an encryption step before a cutoff, and nobody holds a bank’s key on a laptop.
Automations push and pull on each counterparty’s schedule, and a sync connects to the bank’s SFTP or host-to-host endpoint with its host key pinned and its credential held in Files.com. The Files.com Agent reaches an ERP export folder inside your network without an inbound port.
Banks whitelist the source of every SFTP connection. A Files.com custom domain carries two dedicated IP addresses, so the bank has fixed addresses to allow and your finance systems can change behind them without a re-whitelisting cycle.
Expectations know the settlement file is due by six and the acknowledgement by seven, and open an incident when either is late or malformed. The audit log records every transfer, so a question from the auditor or the bank is a lookup.
A multi-tenant layer over Google Cloud Storage kept each bank’s environments and encryption separate while giving MANTL reusable infrastructure for new integrations.
Read The Story
The challenge was breadth, not volume: an under-10-GB footprint spanned banks, suppliers, e-commerce, and overseas branches, all under one encryption requirement.
Read The Story
A feed-by-feed parallel migration kept student-data flows running while a two-person team standardized transfers across internal systems and external vendors.
Read The Story
Files.com automated critical exchanges with banks, agencies, and internal teams while PrePass kept most data in the Azure storage its systems already used.
Read The Story
“The biggest challenge that Files.com helps us solve is keeping our file transfers secure. We rely most on the ability to keep our data encrypted while it’s stored at rest as well as in transmitting the data.”
“Simplicity, reliability, and speed of use. The uptime alone has been worth it — we've barely had a downtime issue.”
The three ways payment files reach the bank today, and where each one puts the control.
Someone exports the batch, encrypts it by hand, and uploads it to the bank portal before the cutoff. It works until that person is out, the cutoff moves, or the positive-pay file is forgotten on the day a fraudulent check clears.
Each bank gets its own script with its own credentials, key handling, and quirks, on a server someone patches. When the bank rotates a key or changes an endpoint, the person who wrote the script is the only one who can fix it.
A server you patch and credential for years so that banks can connect to it, or a legacy MFT product that takes months to implement one job. Both are infrastructure whose only purpose is moving a file the bank could have taken from anywhere.
What treasury, accounts payable, and finance-systems teams ask before moving bank exchange onto Files.com.
The ERP or accounting system writes the ACH batch into a Files.com folder, directly, through a mount of your cloud storage, or through the Files.com Agent from an on-premises export folder. A folder rule encrypts it with the bank’s PGP key, and an Automation delivers it to the bank’s SFTP endpoint before the cutoff, named the way the bank’s intake expects. Files.com logs the delivery and pulls the acknowledgement back.
Yes. Store the bank’s public key and your private key in the PGP key manager, attach them to the bank’s outbound and inbound folders, and every file is encrypted on the way out and decrypted on the way back without anyone running a step. A scheduled sync pulls the acknowledgement and settlement files from the bank on its cadence.
The check register lands in the bank’s outbound folder from your ERP, and an Automation delivers it to the bank’s endpoint on the daily schedule in the format the bank requires. An Expectation confirms the register went out by the deadline and alerts treasury if it did not, so the fraud control never quietly lapses for a day.
Yes. Files.com connects to the bank’s or processor’s SFTP server as a client, pins its host key, pulls on the schedule you set, decrypts the files if they arrive encrypted, and lands them in your own cloud storage or on an internal server through the Files.com Agent, where reconciliation reads them. The credential lives in Files.com rather than in a script.
Yes. A Files.com custom domain includes two dedicated IP addresses for outbound connections, so the bank has fixed addresses to whitelist, and PGP encryption is applied as a folder setting with the bank’s key. Enterprise sites can bring their own IP ranges and keep the whitelist entries the bank already holds.
Yes. Each business client gets its own folder and credential on a Files.com site under the bank’s own domain, uploads over SFTP or a browser, and never sees another client’s files. An Automation routes each file to the core processor or verification vendor on arrival, and the audit log records who uploaded what and when.
Yes. Each bank, processor, and card network is its own connection with its own folder, key, schedule, and addressing on one Files.com site, so treasury and accounts payable run every counterparty from one place. Adding the next bank is a connection and a folder rather than another script.
Point the ERP export at a Files.com folder and let Automations deliver on the bank’s schedule, encrypted, with the acknowledgement pulled back. The person who ran the morning transfer becomes the person who receives the alert on the rare day a file is late, and the audit log replaces the spreadsheet that tracked what went out.
Every delivery, pull, encryption operation, and download is recorded in the Files.com audit log, immutable and retained for seven or more years, and can stream to your SIEM. Files.com is SOC 2 Type II and PCI DSS certified, so the platform’s own controls come with attestations the auditor can read.
Encryption with each bank’s key as a folder setting, delivery on each bank’s schedule from addresses it can whitelist, and the acknowledgements back before reconciliation. Talk to us about the banks and processors you exchange files with.
No pushy sales process
