TrueACH Release September 2026

What's new in TrueACH

This release adds stronger sign-in security, more control over batch transactions, and new options for integrations. Highlights include multi-factor authentication, single sign-on, new Company and Originating Account fields, and an API for contributing ACH returns.

• Multi-factor authentication (MFA): Admins can require users to verify their sign-in with email, text message, or an authenticator app.
• My Info page: Users can update their profile, choose a default MFA method, and manage trusted devices.
• Single sign-on (SSO): Users can sign in with their organization’s identity provider instead of managing a separate TrueACH password.
• Decisions on unvalidated transactions: Accept or decline a batch transaction before it has been validated.
• Updated default batch rule: New query types now start with an “Exclude all batch records” rule so no transactions are queried until you create your own Batch Rules.
• Company and Originating Account fields: Search, view, and submit more information about the originating side of an ACH transaction.
• ACH Return Contributions API: Contribute ACH returns directly through an API instead of SFTP.

Multi-factor authentication (MFA) and user profiles

TrueACH now supports multi-factor authentication (MFA), giving financial institutions an additional layer of security when users sign in. Once MFA is enabled for your institution, users will be required to verify their access to the TrueACH portal using email, text message, or a third-party authenticator app (such as Google Authenticator or Microsoft Authenticator).

We’ve also added a new My Info page to the user menu in the upper-right corner of TrueACH to make MFA easier to manage. Users can update personal information on their profile, including:

• First name
• Last name
• Email address (used for the email MFA method)
• Cell phone (used for the text message MFA method)
• Password

The My Info page also includes two new controls for MFA:

• Default MFA method: Users can change their default method of verifying with MFA (text message, email, or authenticator app). The default is the method the user first enrolled with.
• Trusted devices: Users can review the list of trusted devices on their account and revoke any they do not recognize. A user can have up to five trusted devices.

MFA is turned off by default. Admins can turn it on anytime from the Security Settings section of the Configuration screen under Settings. Turning it on enables MFA for all of your institution’s users. Admins can also decide how often users are prompted to complete MFA again, from every login to every 30 days, based on your security needs.

As an admin, how do I enable MFA for my institution?

1. Go to Settings in the main menu, then select Configuration.
2. In the new Security Settings section, choose your settings:
3. Enable MFA: Turns on MFA for all of your institution’s users. This is off by default.
4. Require MFA Verification: Available only when Enable MFA is set to Yes. This controls how often users must complete MFA when they sign in. The default is every seven days. Other options are every login, every 24 hours, every 14 days, and every 30 days.
5. Click Save Changes.

As an admin, how do I reset MFA for a specific user?

1. Go to Settings in the main menu, then select Users.
2. Find the user and choose to edit that user.
3. In the new MFA Settings section, select Reset MFA. This is available if the user has completed MFA enrollment.

If a user has not yet completed MFA enrollment, their status shows as Not Onboarded and MFA cannot be reset. They will be prompted to enroll the next time they sign in.

As a user, how do I manage my MFA settings?

1. Click your username in the upper-right corner of the portal, then select My Info.
2. On the My Info page, you can change your email address, update your password, and add a phone number for MFA notifications.
3. In the new MFA Settings section, you can change your Default MFA Method (email, text message, or authenticator app) and view and revoke Trusted Devices. This is available once you have enrolled in MFA.
4. Click Save to apply your changes.

Action required to turn on MFA: MFA is off by default. Admins can turn it on anytime from Settings > Configuration under Security Settings.

BENEFIT: MFA provides stronger protection against unauthorized account access by requiring a secondary verification step beyond a password.

Single sign-on (SSO) for TrueACH

Organizations can now configure single sign-on (SSO), allowing users to sign in with their organization’s identity provider rather than managing a separate TrueACH password. Automatic provisioning of users is not included in this release.

No additional user action is needed.

BENEFIT: SSO simplifies user access while allowing organizations to centralize authentication and access management.

Accept or decline unvalidated batch transactions

You can now make an Accept or Decline decision on a batch transaction that has not yet been validated. Previously, no action could be taken until the transaction had completed validation. You can now accept or decline unvalidated transactions from the Batches screen in TrueACH.

When an unvalidated transaction is declined, it is excluded when the NACHA file is regenerated.

How do I accept or decline an unvalidated transaction?

1. Open the batch from the Batches screen.
2. Locate the unvalidated transaction.
3. Select Accept or Decline.
4. If you declined the transaction, it will be excluded when the NACHA file is regenerated.

No setup is required. Use this option on the Batches screen whenever you need it.

BENEFIT: You can respond to questionable or unwanted transactions directly within the batch, even when a validation result is unavailable.

Updated default batch rule configuration

TrueACH now uses an “Exclude all batch records” rule as the default Batch Rule condition. Previously, the default was “Matches any batch record,” which could cause transactions to be queried before an administrator had the chance to create Batch Rules specific to your institution.

The new default rule is created when any of these Query Types is enabled:

• Account Status Only
• AOA Only
• Account Status + AOA

When a Query Type contains only the default “Exclude all batch records” rule, no transactions are submitted for that Query Type. Transactions become eligible for validation only after you create at least one Batch Rule that evaluates to a match.

If your institution was using the former “Matches any batch record” default, it has been updated to “Exclude all batch records.” Batch Rules your institution created remain unchanged.

No action required. This update applies automatically.

BENEFIT: The new default prevents unintended queries and gives your administrators explicit control over which transactions are selected for each Query Type.

Company and Originating Account fields

TrueACH now supports additional company and originator information through the portal, the ACH Validation API, and custom batch file workflows. These values give more complete information about the originating side of an ACH transaction. The following optional fields have been added:

• Originating Routing Number
• Originating Account Number
• Company Name
• Company ID
• Company Entry Description

ACH query screen. The five new fields are available as optional search criteria, so you can find transactions by company or originator information when those values were supplied with the transaction. The query layout has been reorganized: Originating Routing Number and Originating Account Number are shown separately from the receiving Routing Number and Account Number, and Company Name, Company ID, and Company Entry Description are available as optional criteria.

ACH Validation Results. Any company and originator information returned now appears in the Originator section of the expanded ACH Validation Results view. The Account Number label in that section is now Originating Account Number.

ACH Validation API. The request and response models now support originatingRoutingNumber, originatingAccountNumber, companyName, companyId, and companyEntryDescription. API descriptions for the existing routing and account fields have been clarified so integrators can tell receiving information from originating information. The response includes the new properties even when no values were submitted, and properties without values return null.

Custom file formats. You can now use the Company and Originating Account fields in custom file formats. The File Formats > Add New Format wizard includes column mapping for the new fields under Optional Fields. The standard NACHA file format is not changed by this enhancement.

As a portal user, how do I query by Company or Originating Account fields?

1. Go to the ACH query screen in TrueACH.
2. Enter one or more of the optional query values: Originating Routing Number, Originating Account Number, Company Name, Company ID, or Company Entry Description.
3. Use Originating Routing Number and Originating Account Number for the originating account. The standard Routing Number and Account Number fields continue to represent the receiving account.
4. Run the query.
5. Review the Company and Originating Account criteria in the Query panel on the results screen.

As an admin, how do I use these fields in batch files with a custom file format?

1. Add columns with the applicable Company and Originating Account information to your custom batch file.
2. Go to File Formats in TrueACH.
3. Open the Add New Format wizard and paste in your header.
4. Find the Company and Originating Account fields in the Optional Fields panel.
5. Map only the fields included in your custom file. All five fields are optional.
6. Complete the wizard and save the custom file format.
7. Use the configured format when you upload the applicable batch file.

As an API user, how do I include these fields in my API request?

1. Use the AchValidateRequestV4 request model.
2. Continue using routingNumber for the receiving routing number and accountNumber for the receiving account number.
3. Add any applicable optional originating properties: originatingRoutingNumber and originatingAccountNumber.
4. Add any applicable optional company properties: companyName (alphanumeric, maximum 16 characters), companyId (alphanumeric, maximum 10 characters), and companyEntryDescription (alphanumeric, maximum 10 characters).
5. Submit the ACH validation request.
6. Expect the fields to return null in the response when values were not provided.

No action required. The new fields are optional and can be supplied through the portal, the API, or a configured custom file format.

BENEFIT: The new fields give FIs more context about who originated a transaction and allow activity to be searched, displayed, integrated, and reviewed from the originator’s perspective.

New ACH Return Contributions API

A new ACH Return Contribution API endpoint lets integrated institutions contribute ACH returns directly to TrueACH without submitting them through SFTP.

The new endpoint is: POST /Contribute/AchReturns

A single AchReturns request can contain one or more ACH Return entries, allowing bulk contribution of returns. Requests with multiple ACH Returns are processed as a single unit. If any entry fails TrueACH validation, no ACH Return records from the request are created, and the error response includes all identified errors to make them easier to fix.

Each ACH Return requires the following fields:

• RoutingNumber: Nine numeric digits identifying the RDFI associated with the original transaction.
• AccountNumber: Between 1 and 35 characters, with leading zeroes preserved.
• ReturnReasonCode: A valid NACHA Return Reason Code in the R## format.
• Amount: A decimal transaction amount.

The endpoint also accepts these optional values for each ACH Return: Company Name, Company Entry Description, Company Discretionary Data, Company Identification, SEC Code, Entry Date, Receiver Name, Original Entry Trace Number, Date of Death, Original Receiving DFI Identification, Addenda Information, and Return Trace Number.

When TrueACH cannot locate a banking account using the submitted routing and account numbers, it attempts to create the account through the existing account-onboarding process, provided the routing number is valid and can be resolved.

Field formatting and API request errors return an HTTP 400 response, with error details that identify the affected return (entryIndex) and the offending field (field), so you can find the invalid entry in a request with multiple returns. TrueACH validation failures return HTTP 200 with error details in the response body. Examples include an unresolved routing number, an unsupported Return Reason Code, or a banking account that cannot be created.

Full IAT transaction support is outside the scope of this enhancement.

As an API user, how do I submit one or more ACH returns in a single request?

1. Submit one or more return entries to POST /Contribute/AchReturns.
2. Include Routing Number, Account Number, Return Reason Code, and Amount for every entry.
3. Include any applicable optional company, trace, SEC Code, date, or addenda values.
4. Review the response status and processed count.
5. For an invalid request, use entryIndex and field to identify the value that must be corrected.

No action required unless you want to use the new endpoint. Integrators can start contributing ACH returns through the API whenever they are ready.

BENEFIT: Integrated institutions can contribute ACH Returns using a structured API rather than creating and transmitting a separate return file.

Also fixed

• Improved the messaging displayed when file processing failures occur on the Uploaded Files screen.
• Added manual refresh to the Upload screen. Automatic refresh now runs every five minutes.

No action required. These updates apply automatically.