In 2026, the best option for each financial file flow depends on the workflow: SFTP or FTPS for batch ACH, AS2 for signed-receipt proof with secondary-market investors, and a managed MFT platform for evidence. Match the transport to the rule, not to habit.
Last Tuesday the IT manager at a $400M-asset Manteca credit union passed her external auditor’s email to the CIO: C-grade on file transfer, seven outbound flows across five mechanisms, no single source of evidence the way the credit union believed they worked. Phase 2 of NACHA’s Risk Management Topics rule takes effect Monday, June 22, 2026 — the next banking day after the Juneteenth holiday — and the credit union’s ACH origination volume is well below the Phase 1 six-million-entry large-originator threshold.1
The largest banks and credit unions cleared Phase 1 on March 20, 2026. Phase 2 removes the volume threshold entirely, so a Manteca credit union with 600,000 ACH entries a year has the same two banking days to put documented, risk-based processes in place as a national bank does.1 The auditor underlined one phrase twice: “documented, risk-based processes.”
If you read the rest of this article as that CIO, the question is not “which protocol is most secure.” It is “which protocol is most defensible for this specific flow, given the rule that flow answers to.”
What does “securely” mean for a community institution in mid-2026?
Four rule families have a vote in how any financial file leaves or enters your institution, and they do not always agree.
NACHA Operating Rules
NACHA governs ACH origination and receipt. Phase 1 of the Risk Management Topics amendment took effect March 20, 2026 and applied to ODFIs and large non-Consumer Originators with 2023 origination volumes of six million or greater, plus RDFIs with 2023 receipt volumes of ten million or greater. Phase 2 eliminates the volume threshold and applies to every remaining originator, Third-Party Service Provider, Third-Party Sender, and RDFI.1
GLBA Safeguards Rule
The FTC-administered safeguards framework requires a written information security program covering customer information across every system, including the channels it moves through. The 30-day breach notification obligation has been in effect since May 2024.2
FFIEC and the post-CAT framework landscape
The FFIEC retired its Cybersecurity Assessment Tool on August 31, 2025, after OCC Bulletin 2024-25 announced the sunset the prior August. Community institutions now self-assess against the NIST Cybersecurity Framework 2.0, CISA Cybersecurity Performance Goals, or CIS Controls, with the file-transfer perimeter in the System and Communications Protection and Supply Chain Risk Management families.3
Credit-union examiners (NCUA)
The NCUA’s January 2026 supervisory priorities letter put payment-system security, third-party risk management, and separation of duties on the front of the examination binder. Examiners in 2026 will check not just whether a credit union has a contract with its core processor but whether it can produce evidence of actual file exchanges.4
When CJIS joins the perimeter
If your credit union banks a county government or a sheriff’s office, any payment tracing back to law-enforcement funds brings the CJIS Security Policy onto the same perimeter. CJIS v6.0, published December 27, 2024, reorganized the policy into twenty control families aligned with NIST 800-53 and tightened the encryption-in-transit rule to FIPS 140-3 validated cryptographic modules, with AES at 128-bit strength for CJI leaving a secure location and AES at 256-bit strength at rest.5
A “secure” file transfer at a community institution in mid-2026 is one the credit union can evidence against all four families on the day the auditor — or the NCUA examiner — asks.
Which transport fits which financial file flow?
Industry guides to how banks exchange files with ACH processors and core vendors keep returning to four protocols: SFTP, FTPS, AS2, and HTTPS / REST APIs.6 Each is reasonable. None is automatically right.
The four compared
| Transport | How it secures the file | Evidence it leaves | Best fit | Common failure mode |
|---|---|---|---|---|
| SFTP (SSH File Transfer Protocol) | Encrypted SSH session with server-side keys | Server-side audit log; no signed receipt per file | Batch ACH origination and end-of-day core extracts6 | SSH key sprawl when each vendor maintains its own key outside IT inventory |
| FTPS (FTP over TLS) | TLS encryption across FTP control and data channels | Server-side log; can layer client certificates | Vendor reconciliation files; smaller monthly extracts6 | Firewall friction when implicit vs. explicit TLS is set wrong |
| AS2 | Signs and encrypts each file and returns a signed MDN proving it arrived6 | Built-in signed receipt per file — the artifact examiners expect | Secondary-market loan-sale delivery to GSEs; signed agreements with large vendors | Higher operational cost; justified only when the receipt IS the deliverable |
| REST API over HTTPS / webhooks | TLS 1.2+; OAuth or mTLS | Application-layer logs; no native file-level receipt | Origination to fintechs acting as NACHA Third-Party Senders1; real-time balance pulls | API keys left in source-code repos; v1 endpoints left open after v2 launches |
SFTP is the workhorse but is not a strategy. The Manteca team had been treating “secure” as a single attribute and missing the receipts each flow actually needs. AS2 was right where the rule is to prove a specific loan file landed. A REST API was right for the fintech partner acting as a NACHA Third-Party Sender — because the rule there is segregation of duties between originator and TPS, and an API is what makes that segregation programmable rather than policy-on-paper.
How do we build a channel-by-channel evidence map?
Filling in the matrix
The next move was to draw every outbound financial flow as a row in a matrix. Every row had six columns: source system, destination, data class, the rule that touches the flow, the transport, and the evidence the auditor sees.
| Channel | Data class | Rule that answers to it | Transport chosen | Evidence the auditor sees |
|---|---|---|---|---|
| Corporate ACH origination (payroll + vendor) | NPI + payment data | NACHA Risk Mgmt Phase 21; GLBA Safeguards2 | SFTP via core processor (Fiserv) | Core’s batch ACK log + Datapath-side wrapper log |
| Member direct-deposit ACH | NPI | NACHA Risk Mgmt Phase 21; GLBA Safeguards2 | SFTP via core processor | Same as above, segregated by client ID |
| Secondary-market loan-sale delivery to GSE | NPI + loan tape | GLBA2; GSE counterparty contract | AS2 with signed MDN | MDN receipt per file stored in MFT |
| Bankruptcy trustee remittance reporting | Court + payment | Federal Rules of Bankruptcy Procedure | SFTP, scheduled | Datapath wrapper log + trustee portal ACK |
| Outgoing wire transfers | NPI + payment | FFIEC Funds Transfers BSA/AML manual; NCUA core examination4 | TLS bank portal with dual control | Bank-side wire log reviewed daily |
| County disbursement (with CJIS-touching funds) | NPI + restricted CJI | CJIS Security Policy v6.05; NCUA third-party priorities4 | SFTP via MFT with FIPS 140-3 module + AES-256 at rest | MFT audit log + key custody evidence |
Why naming the rule per row is what makes it defensible
When the auditor asks “show me the receipt for this loan file,” the answer is the AS2 MDN in the MFT platform. When the NCUA examiner asks “show me how you separate origination and approval on a $200K wire,” the answer is the dual-control workflow inside the MFT wrapper. When a CJIS auditor asks “where is the FIPS 140-3 module,” the answer is the line on the relevant row. This is what a “best practices listicle” cannot reproduce.
Why does “just use SFTP” break at Phase 2?
NACHA Phase 2 does not pick a transport. It replaces the old “commercially reasonable” standard with a documented, risk-based standard and requires an annual review of those processes.1 If our Manteca credit union’s evidence file were a pile of Outlook S/MIME encrypted emails forwarded around operations, the controls would look like this on paper:
- Originators, TPSPs, TPSs, and RDFIs must implement risk-based processes and procedures reasonably intended to identify ACH Entries initiated due to fraud.1
- The processes must be reviewed at least annually.1
- The credit union must be able to demonstrate that the implementation actually works.
The plain-language differential
Those three bullets demand far more than they name:
- Per-flow evidence: every ACH origination or return flow must leave a record pullable on demand — within minutes, not after a vendor ticket.
- Annual review: the risk-based processes must be documented, time-stamped, and signed — the credit union’s own review, not only the core processor’s SOC 2.
- Third-party scope: TPSPs and TPSs under NACHA must be inside the perimeter. Most small credit unions stop at the core-processor contract and never inventory the payroll vendor, the bankruptcy-trustee remittance service, the secondary-marketing intermediary, or the fintech recurring-ACH partner.
- Originator / RDFI separation: Phase 2 makes RDFIs responsible for monitoring inbound credit entries. A credit union on one side of the ACH network still has to evidence the inbound side.
A “just use SFTP” answer falls down on the first two bullets: SFTP alone does not generate the per-file evidence the credit union’s own auditor expects, and an annual review confined to the core-processor contract misses every Third-Party Sender the credit union never knew it had.
What happens when a financial flow runs into CJIS territory?
The wrinkle that surfaced during the walkthrough
The credit union banks the County of San Joaquin, and one disbursement flow it handles on behalf of the County touches funds the County auditors trace back to the Sheriff’s Office. The flow itself is not criminal-justice data, but the underlying funds fall under the CJIS Security Policy when the County pays vendors through the online banking portal.
CJIS v6.0 reorganized the policy into twenty control families aligned with NIST 800-53, mapping cleanly to NIST CSF 2.0 that community institutions adopted after the FFIEC CAT sunset on August 31, 2025.35 What changed on the wire-room side:
- The transmission rule now requires FIPS 140-3 validated cryptographic modules for CJI in transit.5
- Data leaving a secure location has to use AES under FIPS 197 with at least 128-bit strength.5
- CJI at rest requires AES at 256-bit strength with documented integrity protections.5
The Manteca team was already meeting GLBA for AES-256 at rest because the core processor’s hosted vault is GLBA-aligned. The CJIS wrinkle is that any flow touching these funds now requires evidence that strong encryption is on the wire-room workstation — not just the vault. That is a workstation hardening and key custody problem, not a transport problem, but it lives in the same evidence file.
One credit union, one MFT platform, one place to evidence FIPS 140-3, key custody, and AES-256 at rest. Three audit deliverables, one control surface.
What should a defensible file stack actually produce?
Five evidence artifacts a defensible stack produces without manual work
- A signed receipt (AS2 MDN or equivalent vendor ACK) per batch file exchange, retained for the regulator’s retention period.
- A per-user audit trail — who initiated each upload or download, the file’s hash, the destination, and the cryptographic module that protected the data in transit.
- An annual review binder showing which risk-based processes were tested, which failed, and what changed — satisfying the Phase 2 annual review explicitly.1
- A third-party inventory covering all NACHA TPSPs and TPSs, with each one’s SOC 2 attestation date and the standing of the contract — satisfying both NACHA and the NCUA’s 2026 third-party priorities.4
- A CJIS-aligned control surface (where applicable) showing FIPS 140-3 modules and AES strength per flow.5
None of those artifacts require a particular vendor. They require that channel-by-channel decisions stop being scattered across inboxes and spreadsheets and become one file the credit union can hand the examiner.
Where do you start on Monday morning?
Pull seven colleagues into a room: IT, wire room or ACH operations, compliance, member services, and the CIO. Pull up the matrix above. Fill in every outbound financial flow with the destination, the data class, the rule that answers to it, and the transport you actually use today. Every row that reads “personal Gmail, encrypted email, Outlook S/MIME, vendor portal, CD-ROM handoff, SharePoint link” is a row to fix first.
For a $400M-asset community credit union, that is roughly two weeks of scoping and another four to six weeks to consolidate onto a single managed file transfer platform with wrap-around log retention. Not a small project, but the right size for the rule.
If you want help sequencing that work, our team runs NACHA Phase 2 readiness and evidence-backed file-transfer consolidations across our credit union and community bank clients here in the Central Valley and across our Ohio finance clients in Dublin and Columbus. The starting point is a one-hour walkthrough of your channel matrix against the four rule families named above. If you’d like to see how we have helped a peer institution tighten their file perimeter without slowing the ACH window, our GLBA data mapping guide for credit unions and our ACH fraud prevention and positive pay controls guide are good companions to read first. We can scope a Phase 2 readiness review or a tighter managed cybersecurity and IT operations engagement once we have seen your file flows.
The auditor’s email that opened this article ended with the sentence the CIO read out loud: “We are not judging the protocol; we are judging the evidence.” That is the sentence we would like every financial file your institution touches to live behind.
