Same Data. Different File. Every Single Bank. That Is the Problem Nobody Warned You About

Every bank that offers positive pay needs the same information: check number, amount, date, payee name, account number. The data is identical regardless of institution. The file that delivers it is not. Every bank defines its own layout, its own field order, its own delimiter, its own date format, and its own header and trailer record requirements. A positive pay file format that works at one bank will be rejected at the next. For finance systems teams managing SFTP bank integration across multiple institutions, this means building and maintaining a separate file specification for every banking relationship. The data never changes. The packaging changes every time.

The Variation Is Not Minor. It Is Structural.

Two banks requesting the same five fields can require entirely different files. One expects a fixed width layout with the check number in positions 1 through 10 and the amount right justified with leading zeros in positions 11 through 21. Another expects a comma delimited file with a header row, the amount formatted with a decimal, and the date in YYYYMMDD rather than MMDDYYYY. A third expects a pipe delimited file with no header, the payee name truncated to 40 characters, and a trailer record containing the batch total. Bank file format differences are not cosmetic variations. They are structural incompatibilities that require distinct file generation logic for every institution. We often see organizations maintaining 4 to 8 unique positive pay file specifications simultaneously, each documented in a different format and each maintained by a different combination of people.

The ERP Does Not Solve This Problem. It Creates It.

Most positive pay files originate from the ERP's accounts payable module. The ERP generates a payment file or a check register that contains the issuance data. The problem is that the ERP produces one output format. The banks expect many. Someone has to transform the ERP output into each bank's specific positive pay file format. That transformation happens in one of three places: a custom script written by IT, a middleware tool that maps fields between systems, or a spreadsheet where someone manually reformats the data before transmission. Each approach introduces a maintenance burden and a failure point. Treasury data standardization does not exist at the file level because no two banks agree on what the file should look like.

SFTP Adds a Delivery Layer With Its Own Complexity

Once the file is formatted, it needs to be delivered. Most banks receive positive pay files via SFTP. Each bank specifies its own SFTP endpoint, directory path, file naming convention, and delivery window. One bank expects the file in a directory called /inbound/ppay with a naming convention that includes the account number and date. Another expects it in /uploads with a static file name that gets overwritten each cycle. SFTP bank integration for positive pay is not a single connection. It is a matrix of bank specific delivery configurations layered on top of bank specific file formats.

• Bank A expects a fixed width file named PPAY_ACCT_YYYYMMDD.txt delivered to /inbound before 3 PM EST

• Bank B expects a CSV with headers named positivepay.csv delivered to /upload/checks by 5 PM CST

• Bank C expects a pipe delimited file with a trailer record delivered to /data/incoming with no naming requirement but a 2 PM PST cutoff

• Bank D expects the same layout as Bank A but with an additional field for subsidiary code and a different date format

Each combination of format and delivery specification is a unique integration that must be built, tested, and maintained independently.

One Field Change at One Bank Breaks One Pipeline

Bank file format differences would be manageable if the specifications were static. They are not. Banks update their positive pay requirements periodically. A new field is added for payee matching. A character limit changes on the check number field. A trailer record now requires a hash total instead of a record count. Each change is minor from the bank's perspective. From the finance systems team's perspective, it is a pipeline update that requires modifying the transformation logic, testing the output, and confirming the bank accepts the new file. We often see at least one positive pay file specification change per year per bank, meaning an organization with six banking relationships is handling six format maintenance events annually that were never part of anyone's project plan.

What Arpari Provides as the Format Translation Layer

Positive pay is not just about issuance. Voided and cancelled checks must also be reported to the bank so the file stays current. Some banks accept voids in the same file as issuances with a status indicator field. Others require a separate void file with its own format. Others require voids to be entered manually through the bank portal because their SFTP channel does not support void records. The void process is frequently the weakest link in positive pay operations because it is the step most likely to be handled inconsistently or forgotten entirely. Treasury data standardization breaks down further when the same economic event, cancelling a check, requires a different process at every bank.

Arpari sits between the ERP and the banks, handling positive pay file format translation as a managed capability. The ERP produces one output. Arpari transforms it into every bank's required specification, including field mapping, formatting, delimiter conversion, header and trailer generation, and void handling. SFTP bank integration is managed at the platform level, with each bank's delivery configuration maintained centrally. When a bank changes its specification, the platform absorbs the update rather than surfacing it as an internal IT ticket. Finance systems teams transmit one file to one platform and every bank receives exactly what it expects. The format problem disappears because the translation layer handles it before it reaches the team.

Key Takeaways

The positive pay file format problem is one of the most underestimated operational burdens in treasury. Every bank requires the same data packaged in a different structure, delivered through a different SFTP configuration, on a different schedule. ERPs produce one output. Banks expect many. The transformation between them is maintained through custom scripts, middleware, or manual processes that break every time a bank updates its specification. Void handling adds a second layer of format variation on top of the first. The finance systems teams that manage this efficiently are not the ones with better scripts. They are the ones that introduced a translation layer between the ERP and the banks so the format problem is solved once rather than rebuilt for every institution. The data is always the same. The file should be someone else's problem.

See it in action
Welcome to the next level of clarity from Arpari. Want to try it live? Book a 30-minute demo at www.arpari.com/demo to see how Arpari handles positive pay file formatting and SFTP delivery across all your banking relationships from a single platform.

Arpari is the modern treasury platform for real estate owners, operators, and finance teams. We aggregate bank data, automate cash reporting, and now let you move money securely, across every bank, in one workspace.

‍