ACH Authorisation, SEC Codes and Mandates. A practitioner deep dive into ACH authorization and agreement models, SEC-code selection, consumer and corporate authority, Standing Authorizations, proof, revocation, evidence, controls and testing.
An ACH payment should never be understood only as a file record with an account number, amount and date. Before an Originator creates the entry, there must be a valid business and legal basis for moving money. In the ACH world, that basis is normally expressed through authorization, an agreement between the parties, or another permitted rule framework tied to the specific payment application.
That is why Chapter 9 is not simply a list of Standard Entry Class, or SEC, Codes. A SEC Code tells the ACH Network what kind of application the entry represents. It helps distinguish consumer from corporate activity, single from recurring behavior, credit from debit use cases, the channel through which authorization was obtained, and the record format used for the payment. But a correct SEC Code does not magically create authorization. The authorization has to exist first and must satisfy the requirements applicable to that entry.
This chapter therefore connects three concepts that are often separated incorrectly:
authority to move money → the authorization or agreement that creates that authority → the SEC Code and ACH data that communicate the payment application to the network.
The term mandate is common in global payments and is useful as human banking language, but ACH does not use a single universal mandate model equivalent to SEPA Direct Debit. In U.S. ACH, the operational concepts are more specific: consumer debit authorizations, corporate agreements, Standing Authorizations, Subsequent Entries, source-document conversion notices, oral authorizations, electronically authenticated authorizations and other application-specific evidence. This chapter will sometimes use “mandate” as a convenient implementation term for the bank’s stored authorization object, but the learner should always map that object back to the actual Nacha authorization or agreement requirements.
The chapter stays deliberately inside its boundary. Chapter 7 covered ACH credits. Chapter 8 owns the detailed ACH debit-collection lifecycle. Chapter 10 owns Same Day ACH. Chapter 11 owns returns, reversals and Notifications of Change. Chapter 12 owns deeper ACH fraud controls. Chapter 13 owns exception research. Here, those subjects appear only where they are necessary to understand authorization governance and SEC-code correctness.
A useful mental model is:
business relationship → Receiver consent/agreement → authorization evidence → payment instruction → SEC-code decision → ACH entry → ODFI validation → ACH Network → RDFI processing → evidence retention → revocation/change/exception handling.
For a roughly 60-minute core session, spend about 35 minutes on Sections 1–4, Sections 6–8 and Sections 12–13. For the next 10 minutes, use the chapter’s three diagrams to connect the collection channel to authorization and retained evidence. Use 10 minutes to work through one case in Section 16, then spend the final 5 minutes explaining: What would you need to establish before selecting a SEC Code for a new collection journey? Treat these timings as a study guide. The remaining sections, additional cases and extended reference material are follow-up study; completing the whole chapter takes longer.
Chapter navigator
- What ACH authorization really means
- Who authorizes what: Originator, Receiver, ODFI and RDFI responsibilities
- Why the SEC Code matters and what it does not prove
- Consumer versus corporate authorization models
- PPD: consumer Direct Deposit and prearranged debits
- WEB and TEL: internet, mobile and telephone authorization
- CCD, CTX and corporate agreements
- Standing Authorizations and Subsequent Entries
- Check-conversion and specialized SEC Codes
- IAT and cross-border authorization boundaries
- Building a bank-grade authorization record
- Revocation, changes, stop payments and lifecycle state
- Proof of authorization, retention and evidence requests
- Authorization failures, unauthorized entries and false pretenses
- Controls, reconciliation, reporting and real-bank operating design
- End-to-end cases, BA checklist and testing
1. What ACH authorization really means
Authorization is the point at which a payment changes from an idea into an instruction that a party is permitted to originate.
For ACH, the first question should therefore not be “Which SEC Code should I use?” It should be:
Why is the Originator allowed to create this entry against or for this Receiver account?
For a consumer ACH debit, the answer may be a written or similarly authenticated authorization. For a TEL debit, the answer can be an oral telephone authorization that meets the requirements for that application. For a corporate CCD or CTX relationship, the answer is generally an agreement between the companies. For a CIE credit, the consumer instructs a bill-payment service to send the credit. For a check-conversion entry, the authority model is tied to the eligible source document and required notice or authorization framework.
Authorization therefore has both business meaning and evidence meaning.
Business meaning answers: what did the Receiver agree to?
Evidence meaning answers: can the Originator prove that agreement later?
Those two questions must remain connected. A web page can contain beautifully worded terms, but if the Originator cannot show which version the customer accepted, when it was accepted and how the acceptance was linked to that customer, the evidentiary control is weak. Conversely, a technically perfect audit log cannot rescue an authorization whose terms did not clearly explain the debit.
Nacha guidance emphasizes that consumer debit authorizations must be clear and readily understandable and that recurring debit authorizations must explain how the Receiver can revoke authorization for future entries. The form and proof requirements then depend on the ACH application and SEC Code.
Authorization is not the same as authentication
Authentication asks who is acting.
Authorization asks what that person or company permitted.
A customer can successfully log in using multi-factor authentication and still not authorize a specific recurring debit. A call-center agent can correctly identify a caller and still fail to capture the terms required for a TEL authorization. An ERP user can have authority to upload a payment file but not authority to approve it for release.
A bank-grade control model therefore separates:
identity authentication → user entitlement → transaction approval → Receiver authorization/agreement → ACH origination.
These may be performed in one customer journey, but they are not the same control.
Authorization is not the same as account validation
Account validation asks whether the account data is plausible, open or associated with the intended Receiver depending on the method used.
Authorization asks whether the Originator is permitted to create the transaction.
A validated account can still be debited without proper authorization. A properly authorized debit can still contain an incorrect account number. Both controls matter, but they solve different problems.
Authorization is not the same as funds availability or settlement
The Receiver’s consent does not prove the payer has funds. It does not prove the ACH Operator will accept the entry. It does not prove the RDFI will post it. It does not prove settlement has happened.
Authorization belongs near the beginning of the lifecycle. The financial outcome is determined later through ACH processing, settlement, posting and any subsequent exception events.
“Mandate” in ACH should be used carefully
Many global payment professionals naturally use the word mandate to describe a recurring debit instruction. That is reasonable in conversation, but an ACH implementation should not assume a single mandate object with one universal format or set of rights.
A useful internal authorization record can certainly be called a mandate. But the record should know whether the underlying authority is:
- a written PPD debit authorization;
- a similarly authenticated electronic authorization;
- a WEB authorization;
- a TEL oral authorization;
- a Standing Authorization;
- a corporate CCD/CTX agreement;
- a source-document conversion framework;
- another application-specific authority.
The rule logic depends on that type.
The first principle of Chapter 9 is therefore:
authorization is the permission; the SEC Code is the network classification; the stored mandate/authorization record is the bank’s evidence and lifecycle representation.
2. Who authorizes what: Originator, Receiver, ODFI and RDFI responsibilities
The ACH participant chain creates several layers of responsibility.
The Receiver is the person or organization whose account is affected by the ACH entry. For a debit, the Receiver is permitting money to be pulled from the account. For some credit applications, the Receiver’s agreement or instruction can also be relevant, but the strictest authorization discussions usually arise around debits because money is being removed from the Receiver’s account.
The Originator is the party that creates or causes the ACH entry to be created. It has the primary responsibility to obtain the authorization or agreement required for the transaction type it originates.
The ODFI originates the entry into the ACH Network. The ODFI does not merely trust any file sent by a customer. It has responsibilities under the Nacha Rules and under its origination agreement. It therefore needs controls reasonably designed to ensure that the Originator is entitled to originate the entries and is using ACH applications correctly.
The ACH Operator processes the entry according to network rules and format. The operator does not sit between the Originator and Receiver to inspect the original customer authorization for every entry.
The RDFI receives the entry. It normally relies on the ACH rule framework and the warranties attached to origination rather than obtaining the Originator’s authorization record before posting every item. When the Receiver disputes an entry or the RDFI needs proof, however, the authorization record becomes operationally important.
The authorization normally sits outside the ACH file
This is one of the most important architecture lessons.
The ACH file does not carry the customer’s complete authorization document. It carries the payment entry and data required for the ACH application. The legal/evidentiary authorization is usually stored in the Originator’s or service provider’s systems.
That means two separate but linked objects exist:
authorization object — the evidence and terms proving permission;
payment object — the ACH instruction created under that permission.
The bank must be able to link them.
For a recurring debit, many ACH entries can point back to one authorization. For a Standing Authorization, individual Subsequent Entries can be initiated later under the standing terms. For a corporate agreement, large populations of CCD or CTX entries may rely on one bilateral agreement and associated bank service arrangements.
The ODFI needs reasonable visibility into the Originator’s authorization model
An ODFI does not need to manually inspect every authorization before every file is released. That would defeat the scale of ACH. But onboarding and ongoing monitoring should answer basic questions.
What SEC Codes will the customer originate?
How does the customer obtain authorization?
How is proof retained?
How are revocations processed?
How does the Originator prevent an expired or revoked authorization from generating new debits?
How are customer complaints handled?
How are authorization records linked to files and trace numbers?
For higher-risk applications, the ODFI may need stronger due diligence and monitoring.
Third parties add a responsibility layer, not an excuse
A Third-Party Sender, processor, biller platform or payroll provider can perform parts of the origination process. This does not eliminate the need for a valid authorization chain.
If a merchant obtains a WEB authorization but a payment processor creates the ACH file, the processor may never have shown the authorization page to the consumer. The system therefore needs reliable evidence transfer and linkage. The ODFI needs to know which party owns the proof, who can produce it and how quickly.
A useful responsibility map is:
Receiver grants authority → Originator owns business authorization → processor/TPS may capture or transmit evidence → ODFI controls origination relationship → ACH Network processes → RDFI handles receiving account and disputes.
Warranties matter even when the original document is not in the file
The ACH model works because participants rely on rule warranties and obligations rather than exchanging every underlying contract with every payment.
Operationally, this creates a delayed-evidence model. The payment can move first. If there is a dispute later, the evidence chain must be reconstructable.
That is why authorization governance is not just legal documentation. It is payment-operating infrastructure.
3. Why the SEC Code matters and what it does not prove
The Standard Entry Class Code is one of the most important classification fields in ACH.
It tells the network what ACH application is being used. Nacha’s developer guidance explains that SEC Codes generally indicate important characteristics such as whether the transaction is consumer or corporate in nature, whether it is single or recurring, and the specific ACH record format used for the application.
A SEC Code therefore affects:
- what kind of account relationship is expected;
- what authorization method applies;
- whether the entry can be a credit, debit or both;
- what addenda capabilities are available;
- what data the RDFI expects;
- what return and dispute treatment can become relevant;
- what operational controls the ODFI should expect.
But a SEC Code is not evidence by itself.
A batch marked WEB does not prove the customer accepted an online debit authorization.
A TEL code does not prove the call recording exists.
A PPD code does not prove a recurring consumer debit authorization was written or similarly authenticated.
A CCD code does not prove the two companies actually have the required agreement.
The SEC Code says what application the Originator claims to be using. The Originator and ODFI must be able to support that claim.
SEC-code selection should be a rule decision, not free text
A mature payment engine should not let a user arbitrarily type any three-letter SEC Code.
The SEC decision can depend on:
- consumer versus non-consumer Receiver account;
- credit versus debit;
- single, recurring or Subsequent Entry behavior;
- authorization channel;
- source-document conversion use case;
- international dimension;
- remittance/addenda requirement;
- product eligibility;
- account type and terminal/channel conditions where applicable.
This can be implemented through product configuration, eligibility rules and controlled mappings.
The same business relationship can generate different SEC Codes
Consider a customer relationship with a utility company.
A customer may sign a written recurring authorization for monthly debits: PPD can be relevant.
Another customer may authorize a single online debit through the utility website: WEB can be relevant.
Another may call and authorize a debit by telephone: TEL can be relevant.
The biller is the same. The Receiver account may be at the same bank. The commercial obligation is the same. But the authorization channel and ACH application differ.
SEC Code is not routing
The SEC Code does not choose FedACH versus EPN. It does not choose the RDFI. It does not decide whether the item is Same Day ACH. Those are different dimensions.
A useful architecture model separates:
business purpose → authorization model → SEC Code → processing lane/timing → operator route → settlement.
SEC-code errors can be operationally serious
Using the wrong SEC Code can lead to incorrect authorization assumptions, invalid data expectations and dispute exposure.
A customer who gave telephone authorization should not be silently converted into a PPD recurring debit merely because the bank’s file generator only supports PPD. A corporate account should not be forced into a consumer application because a user selected the wrong code.
For a BA, a strong requirement is:
The system shall derive or validate the SEC Code from the Receiver type, transaction direction, authorization method, payment behavior and product eligibility, and shall reject inconsistent combinations.
4. Consumer versus corporate authorization models
Consumer and corporate ACH relationships are not governed by one identical authorization model.
For consumer debits, the Nacha Rules generally require clear authorization terms and specify forms depending on the application. Regulation E can also be relevant to preauthorized electronic fund transfers from consumer accounts.
For corporate entries, the model is more agreement-based. Nacha’s developer guidance notes that for business-to-business ACH, there must be an agreement between the trading partners, and the Rules do not prescribe one universal commercial contract template.
This distinction has major implementation consequences.
Consumer authorization is more prescriptive
A consumer recurring debit authorization needs clear terms and revocation instructions. The authorization method can drive the SEC Code. A WEB debit originated from internet authorization uses the WEB application. A TEL debit uses telephone authorization. PPD is used for prearranged consumer payments/deposits under the applicable PPD framework.
Changes to an ACH debit schedule can also trigger notice requirements. Nacha’s developer guidance summarizes seven calendar days’ notice for a change of date for consumer and corporate entries, while the ten-calendar-day change-of-amount notice applies to consumer entries. The exact obligation still depends on the applicable ACH application, authorization/agreement and rule conditions, so a bank should not turn these into one generic rule for every ACH payment.
The bank should not hard-code these as generic “all ACH change” rules without context. It should know which authorization/application they belong to.
Corporate authorization is relationship-based
For CCD and CTX, the companies have an agreement governing transfers.
The agreement can be embedded in a treasury service contract, trading-partner agreement, cash-concentration arrangement or another commercial structure. The important ACH principle is that the relationship authorizes the corporate entries and binds the parties to the applicable ACH rules.
A bank implementation therefore often stores corporate authority differently from consumer mandate records.
Consumer authorization object might contain:
receiver, account, authorization text version, method, date/time, single/recurring/standing, revocation method, evidence.
Corporate agreement object might contain:
company relationship, service, allowed SEC codes, allowed accounts, credit/debit permissions, limits, effective dates, signatories, contract reference.
Consumer protections cannot be copied mechanically into corporate processing
The existence of a debit dispute does not mean the same Regulation E protections apply to a corporate account. Conversely, calling an account “business” in an internal CRM does not automatically prove the ACH entry should be corporate; the actual Receiver account classification and application must be correct.
One Originator can support both populations
A large insurer could originate consumer PPD credits and debits, corporate CCD payments, WEB consumer debits and other applications.
That means the Originator profile should not have one field called ACH_AUTHORIZATION_TYPE.
It should support multiple products and authorization frameworks by payment population.
5. PPD: consumer Direct Deposit and prearranged debits
PPD, Prearranged Payment and Deposit, is one of the foundational ACH applications.
Nacha’s developer guidance describes PPD as a single-entry or recurring ACH credit or debit sent by an Originator to a consumer account.
PPD covers two very different directions.
A PPD credit is commonly associated with Direct Deposit, such as payroll. The authorization issue is not the same as a debit because the Receiver is receiving funds rather than having money pulled.
A PPD debit is a prearranged consumer debit, such as a recurring bill collection under an appropriate authorization.
Do not teach one PPD authorization rule for both directions
This is a common training mistake.
PPD is an ACH application that supports both credits and debits. But debit authorization obligations are more demanding because the Originator is taking funds from the Receiver account.
The payment engine should therefore derive authorization controls from both:
SEC = PPD
and
transaction direction = credit/debit.
PPD recurring debit example
A consumer signs up for monthly insurance premiums.
The authorization clearly identifies the account to be debited, the recurring nature of the debit and how the consumer can revoke future debits. The Originator stores the authorization evidence and creates a recurring payment schedule.
Each month, the billing system creates the payment instruction. Before origination, the system checks that:
- the authorization remains active;
- the account reference matches the authorized relationship;
- the amount/date fits the agreement or required notice framework;
- no revocation has been recorded;
- the Originator remains entitled to originate;
- the correct SEC Code is used.
The ODFI then receives the entry/file and applies its own controls.
PPD Direct Deposit example
An employer sends payroll credits to employee consumer accounts.
The company has the account instructions supplied by the employee and its payroll authority under the employment/payment arrangement. It sends PPD credits.
This is still an ACH authorization topic because the Originator must be entitled to send credits and should retain valid payment instructions, but it should not be explained as though the employer needs a consumer debit mandate to credit salary.
PPD+ and addenda
PPD can include a single addenda record when the applicable format uses it. The + is often used in industry descriptions to indicate the presence of addenda.
Authorization evidence should not be hidden inside addenda. The addenda supports payment-related information, not proof of the Receiver’s original authorization.
PPD should not become a fallback code
Legacy systems sometimes overuse PPD because it is widely supported.
That is dangerous. If the actual authorization was obtained by telephone or internet and the applicable rules require TEL or WEB treatment, a bank should not select PPD merely because downstream processing is easier.
6. WEB and TEL: internet, mobile and telephone authorization
WEB and TEL make the relationship between authorization channel and SEC Code especially clear.
WEB
WEB is used for consumer debit applications in which authorization is obtained via the internet or wireless network under the WEB rules.
The Originator needs more than a checkbox labelled “I agree.” It needs a defensible authorization process and evidence connecting the customer to the terms.
For a digital journey, useful evidence can include:
- authorization text/version;
- date/time;
- customer/session identity;
- account entered or tokenized account reference;
- affirmative acceptance event;
- authentication evidence;
- device/session metadata where appropriate;
- confirmation delivered to the customer;
- recurring/single/standing classification;
- subsequent revocation or change events.
Nacha industry guidance on WEB proof of authorization emphasizes that when an authorization is similarly authenticated, the Originator should retain the authorization and evidence of the process used to link the authorization to the consumer.
WEB fraud detection and account validation boundary
WEB debits have specific risk expectations, including commercially reasonable fraudulent-transaction detection requirements. Account validation is also closely associated with WEB debit risk controls.
These controls do not replace authorization.
A transaction can pass account validation and still be unauthorized.
A customer can validly authorize a debit from an account that later closes.
The bank should store authorization evidence and risk-control evidence as related but distinct artifacts.
TEL
TEL is used for consumer debit authorization obtained orally by telephone under the TEL framework.
An Originator cannot treat a normal customer-service phone conversation as payment authorization simply because an agent read out an amount. The authorization must satisfy the TEL requirements and the general ACH debit authorization standards.
Nacha’s Meaningful Modernization guidance explains that an oral authorization for a single entry must be supported by an audio recording or written confirmation provided before settlement, and the authorization evidence must be retained for the applicable two-year period. Recurring oral authorization also interacts with Regulation E requirements, including providing a copy of the authorization to the consumer.
Voice over internet does not automatically mean WEB
The communication method matters.
Nacha guidance addresses oral authorizations obtained using internet-connected voice technologies and the way SEC-code rules apply. A BA should not decide based simply on whether the call used the internet as transport.
The business question is how the authorization was obtained from the consumer and which ACH application rule applies.
Standing Authorization can create later channel flexibility
Under the Standing Authorization/Subsequent Entry framework, a Receiver can establish a broader standing relationship and later affirmatively initiate individual Subsequent Entries.
The SEC Code used for those subsequent entries can depend on the way the later instruction is initiated and the terms of the Standing Authorization. Nacha’s Meaningful Modernization guidance provides flexibility in some scenarios, while terminal-originated subsequent entries must still use the applicable terminal SEC Code.
This is one reason authorization engines need more than one static SEC_CODE stored against the customer relationship.
7. CCD, CTX and corporate agreements
CCD, Corporate Credit or Debit, and CTX, Corporate Trade Exchange, are core corporate ACH applications.
Both can support credits and debits to corporate accounts. The authorization foundation is the corporate agreement between the parties rather than the consumer authorization pattern used for WEB, TEL or PPD debits.
CCD
CCD is widely used for vendor payments, cash concentration, account funding and other business-to-business transfers.
A CCD entry can support limited payment-related information through a single addenda record.
The corporate agreement should define the commercial authority. The bank’s treasury service agreement can separately define which users and accounts can originate CCD entries.
These are different layers:
trading-partner agreement — why Company A can debit/credit Company B;
bank entitlement — which Company A user can instruct the bank;
ODFI origination agreement — under what terms the bank accepts Company A’s ACH files.
CTX
CTX supports richer remittance and can carry many addenda records. Nacha developer guidance notes support for up to 9,999 addenda records, making CTX useful for complex trading-partner payments.
The larger data capability does not change the authorization principle. A corporate agreement still needs to support the transfer relationship.
Corporate debit authority needs explicit governance
Corporate users often assume that because two companies have a contract, any ACH debit between them is allowed.
A strong bank implementation should be more precise.
The agreement and bank onboarding should define:
- which company may originate debits;
- which accounts may be debited;
- purpose/product;
- value limits;
- effective dates;
- permitted SEC Codes;
- whether one-time and recurring debits are allowed;
- dispute/escalation process;
- contact and evidence ownership.
Corporate agreement does not mean no evidence
Consumer authorizations often have more prescriptive proof requirements, but corporate ACH should still be auditable.
A bank should be able to answer:
Which agreement allowed this CCD debit?
Was the agreement active on the settlement date?
Was this account within scope?
Was the Originator entitled?
Was the amount within product/contract limits?
Who approved the file?
The evidence may be a contract and treasury entitlement history rather than a consumer authorization form, but it still matters.
8. Standing Authorizations and Subsequent Entries
Standing Authorization is one of the most important modern ACH authorization concepts because it separates the creation of a durable relationship from the later initiation of individual payments.
A Standing Authorization establishes the terms under which the Receiver can later affirmatively initiate Subsequent Entries.
This is not exactly the same as a traditional recurring debit schedule.
In a normal recurring authorization, the Originator can create entries on a recurring basis according to the agreed schedule.
Under a Standing Authorization, the relationship exists, but each Subsequent Entry is initiated later through an affirmative action by the Receiver under the standing terms.
Example: stored payment relationship
A consumer establishes a Standing Authorization with a financial service provider.
The authorization defines the account and the permitted way future debits can be initiated.
Two weeks later, the consumer logs into the app and presses Pay $500.
That affirmative instruction can create a Subsequent Entry.
The bank should retain linkage between:
standing authorization ID → subsequent instruction ID → payment ID → ACH trace.
Standing Authorization is not unlimited permission
The Originator cannot use the existence of a Standing Authorization as a blank cheque.
The Subsequent Entry must be initiated according to the standing terms.
If the standing agreement says the Receiver initiates future payments through an app, the Originator should not silently begin scheduled debits without a Receiver action.
SEC Code can vary for Subsequent Entries
Nacha’s Meaningful Modernization rules allow flexibility in SEC-code selection for certain Subsequent Entries depending on the channel used to initiate them and the standing terms.
However, this flexibility has boundaries. For example, subsequent entries initiated at an electronic terminal need the applicable terminal SEC Code so terminal information is properly carried.
The implementation therefore needs:
- standing authorization method;
- permitted subsequent-initiation methods;
- each subsequent instruction’s channel;
- derived SEC Code;
- evidence that the customer initiated that specific payment.
Oral Standing Authorization
Nacha guidance allows Standing Authorization to be obtained orally under applicable requirements. The Originator must maintain appropriate evidence such as an audio recording or written confirmation and retain it for the applicable period from termination or revocation.
If the standing authority was obtained orally over the telephone, the later SEC-code treatment also needs to respect the specific rules described by Nacha.
Why Standing Authorization improves UX but increases data-model complexity
It allows a customer to establish a trusted payment relationship once and initiate future transactions efficiently.
But the system must now distinguish:
AUTHORIZATION_ACTIVE
from
SUBSEQUENT_PAYMENT_AUTHORIZED_NOW.
Those are separate events.
9. Check-conversion and specialized SEC Codes
Not every ACH debit begins as a digital authorization form or standing instruction.
Several SEC Codes exist for applications in which a check or source document is converted into an ACH debit.
These include applications such as ARC, BOC, POP and RCK, each with its own conditions.
Chapter 9 should teach the authorization principle without becoming a full check-conversion chapter.
ARC — Accounts Receivable Entry
ARC is used for the conversion of an eligible source document received through channels such as mail, delivery service, lockbox or certain in-person bill-payment contexts as defined by the rules.
The authority model includes required notice to the consumer before the source document is accepted for conversion.
The source document is not simply deposited as a check and then magically turned into ACH. The Originator is using a specific ACH application and must satisfy the applicable notice and eligibility rules.
BOC — Back Office Conversion
BOC is based on an eligible source document accepted at a point of purchase or manned bill-payment location and converted later in the back office.
Again, required notice and source-document eligibility matter.
POP — Point of Purchase
POP supports a single ACH debit initiated from an eligible source document presented at a point-of-purchase or manned bill-payment location. The authorization framework is more explicit and historically includes written/similarly authenticated consumer authorization requirements.
RCK — Re-presented Check Entry
RCK is used to collect certain eligible checks that were returned for insufficient or uncollected funds.
Its authority is not based on a new consumer WEB or TEL authorization. It relies on the eligible source item and specific RCK rules.
Why these codes matter to authorization architecture
If a platform receives check conversion as one generic product flag, it can easily apply the wrong evidence logic.
The authorization/evidence model should know:
- which source-document application is used;
- what notice was provided;
- whether the source document is eligible;
- what source-document evidence is retained;
- which SEC Code is generated;
- whether the item can be re-presented or converted under that application.
The detailed check lifecycle belongs later in the USA curriculum, but Chapter 9 must make clear that source-document conversion is its own authorization family.
Other specialized codes
Other ACH applications exist for point-of-sale, machine transfer, shared-network and specialized government or notification use cases.
The lesson is not to memorize every code in one sitting. It is to understand that SEC Code is application semantics. A bank should use the code only when the business event, authorization method, participants and data really match the application.
10. IAT and cross-border authorization boundaries
IAT, International ACH Transaction, adds an international dimension to ACH classification.
Nacha’s current rules define IAT based on whether the ACH entry is part of a payment transaction involving a financial agency office outside the territorial jurisdiction of the United States, with changes to the definition taking effect in September 2026.
IAT can be credit or debit and can involve consumer or corporate relationships.
IAT is not an authorization method
This distinction matters.
IAT tells the network that the transaction has the specified international characteristics. It does not itself describe whether a consumer debit was written, whether a corporate agreement exists or whether a credit instruction was valid.
The authorization model must therefore be determined by the underlying Receiver/payment relationship, while IAT adds the international classification and additional data/compliance expectations.
Cross-border does not remove domestic ACH authorization obligations
An Originator should not assume that because the payment has an international leg, normal ACH authorization governance disappears.
A consumer debit still needs the appropriate authority.
A corporate debit still needs the applicable agreement.
The ODFI still needs evidence and product controls.
Additional international screening, data and compliance requirements can apply on top.
Do not use IAT as a routing substitute
IAT does not mean send through SWIFT and does not identify the correspondent route.
It is an ACH SEC Code describing an international ACH application.
Chapter 51 later covers cross-border alternatives in more depth.
11. Building a bank-grade authorization record
Many payment platforms fail not because they cannot move an ACH file, but because they do not model authorization as a first-class object.
A weak system stores a Boolean:
authorized = true
A stronger system stores an authorization record with lifecycle and evidence.
Core authorization identity
A practical authorization object can contain:
- authorization ID;
- Originator/customer ID;
- Receiver identity/reference;
- Receiver account token/reference;
- authorization type;
- consumer/corporate classification;
- allowed direction: credit/debit;
- allowed SEC Code(s) or derivation rules;
- single/recurring/standing classification;
- effective date;
- expiry date if applicable;
- amount rule or limit if applicable;
- frequency/schedule rule if applicable;
- permitted initiation channels;
- revocation method;
- status;
- evidence location/reference;
- authorization text/version;
- capture timestamp;
- confirmation-delivery evidence where applicable.
Evidence should be immutable even when the relationship changes
If a customer updates a recurring authorization from $100 to variable billing, the bank should not overwrite the old authorization text and pretend it always said variable.
Authorization changes should be versioned.
A payment originated on January 10 should be linked to the authorization version active on January 10.
A dispute raised in March must be reconstructed using the historical version.
Account details may need controlled change
If the Receiver changes bank account, the system should determine whether the existing authorization remains valid for the new account under the applicable terms and legal/rule framework or whether new authorization is required.
This should be a business rule, not an implicit database update.
Authorization state machine
A useful state model can include:
DRAFT
PENDING_CONFIRMATION
ACTIVE
SUSPENDED
REVOKED
TERMINATED
EXPIRED
SUPERSEDED
The exact names are implementation choices. The important control is that a payment engine knows whether the authorization is usable at origination time.
Payment-to-authorization lineage
Every debit payment should be able to answer:
Which authorization allowed me?
Which version?
What SEC Code did that authorization/channel imply?
Was the authorization active when I was created and when I was released?
Was any revocation received before release?
The authorization record should not store unnecessary sensitive data
Evidence design should balance auditability with data minimization and security.
A recording may contain personal information. A document can contain account data. An authorization database should use controlled access, encryption/tokenization where appropriate, retention policies and audit trails.
12. Revocation, changes, stop payments and lifecycle state
Authorization is not permanent simply because it was once valid.
A customer can revoke authorization according to the applicable authorization terms and law/rules. A corporate agreement can terminate. A recurring instruction can expire. A Standing Authorization can be revoked.
The payment engine therefore needs current authority, not historical authority.
Revocation should stop future origination at the right control point
Suppose a consumer revokes a recurring debit authorization at 10:00.
A debit scheduled for tomorrow has already been created internally but not released to the ODFI.
If the Originator has a reasonable opportunity to act on the revocation under the applicable rules/terms, the payment should not simply proceed because the record was generated earlier.
A mature system rechecks authorization status before final release when necessary.
Revocation is not the same as stop payment
Revocation is communication to the Originator ending or limiting the Originator’s authority to initiate future entries.
Stop payment is an instruction from the Receiver to the RDFI not to pay a specific entry or applicable future entry according to the stop-payment rules.
They can address the same unwanted debit from different sides of the relationship.
The bank should not collapse them into one CANCELLED flag.
Change of amount or date
Recurring consumer debit arrangements may require advance notice when the debit amount or date changes beyond the conditions allowed by the authorization/rules.
The authorization model should therefore store enough commercial terms to determine whether a change needs notice.
A billing system that changes an amount should not bypass the authorization engine.
Standing Authorization revocation
Revoking the standing authority prevents future Subsequent Entries under that authority.
It does not retroactively mean that all properly initiated historical Subsequent Entries were unauthorized.
This is important for disputes and reporting.
Corporate agreement termination
For CCD/CTX, contract/treasury product termination should update the origination entitlement.
A corporate customer whose cash-concentration agreement ended yesterday should not still be able to send debit files today because a batch template remains active.
Lifecycle reconciliation
Authorization operations should reconcile:
active mandates/authorizations
against
active payment schedules/templates
and
customer/product entitlements.
This identifies orphan schedules that can create unauthorized future payments.
13. Proof of authorization, retention and evidence requests
Authorization matters most operationally when somebody asks for proof.
Nacha’s public guidance states that Originators must be able to prove permission to transact and provide proof through the ODFI in response to an RDFI request within the applicable timeframe. Nacha restored the standard proof-of-authorization delivery timeframe to 10 Banking Days after the temporary pandemic relief ended in 2022.
Retention is not one universal “two years from payment date” rule
The retention clock depends on the authorization type and lifecycle.
For written or other authorization evidence, Nacha guidance commonly requires retention for two years from termination or revocation of the authorization. Oral authorization rules can have specific retention treatment for single, recurring and Standing Authorizations.
The architecture should therefore store:
- authorization creation date;
- termination/revocation date;
- evidence retention trigger;
- retention category;
- legal hold if applicable;
- destruction eligibility date.
Proof must be reproducible
An authorization screen that existed only in application code is not sufficient evidence if nobody can reconstruct what the customer saw.
For digital authorization, keep:
- the exact authorization text or version;
- evidence of affirmative action;
- evidence linking the action to the Receiver;
- timestamp;
- relevant confirmation record.
For oral authorization, retain the required recording or confirmation evidence.
For corporate agreements, retain the contract/agreement and amendments in a form that can be tied to the ACH relationship.
The ODFI should know where evidence lives
A common operational failure is that the Originator says, “our vendor has it,” the vendor says, “the merchant has it,” and the ten-Banking-Day clock keeps running.
During onboarding, responsibility should be explicit:
evidence owner
system of record
request channel
SLA
backup owner
escalation path.
Evidence request workflow
A mature PoA workflow can look like:
RDFI request received → ODFI case created → Originator/TPS request → evidence retrieved → quality checked → response delivered → case closed → audit trail retained.
The case should link the ACH trace number, Receiver, amount, settlement date and authorization ID.
Returning the entry instead of proof is not always the end of the evidence question
Nacha clarifications recognize scenarios in which an ODFI may accept or agree to accept a return instead of initially providing proof, while a subsequent written proof request can still arise.
Operations should not destroy or ignore authorization evidence simply because a financial return was processed.
14. Authorization failures, unauthorized entries and false pretenses
Authorization failures do not all look the same.
No authorization
The Originator creates a debit without obtaining required Receiver authority.
This is the clearest authorization failure.
Invalid form of authorization
The Receiver intended to pay, but the Originator did not capture the authorization in the form required for the ACH application.
Example: a telephone debit is originated using a consumer SEC Code inconsistent with how authorization was obtained.
Authorization exceeded
The Receiver authorized $100 monthly, but the Originator debits $1,000 without a basis allowed by the terms/rules.
The authorization exists, but the payment may fall outside it.
Authorization revoked
The Receiver validly revoked future authority, but the Originator continued to originate.
Wrong account
The Receiver authorized a debit but the Originator used another account. This can be both a data-quality and authorization-scope issue.
Authorized under false pretenses
Modern payment fraud requires another distinction.
A victim can intentionally authorize a payment because a fraudster deceived them. The payment may have affirmative customer action, yet the authorization was induced by false pretenses.
Nacha’s 2026 fraud-monitoring rules explicitly address entries suspected of being unauthorized or authorized under False Pretenses. The phased requirements apply to ODFIs, non-consumer Originators, Third-Party Senders and relevant Third-Party Service Providers, and to RDFIs receiving ACH credits according to the 2026 implementation schedule.
This is important because traditional authorization evidence alone is not enough to manage scam risk.
A system can have:
AUTHORIZATION_EVIDENCE_VALID = YES
and
FRAUD_SUSPICION = HIGH.
The bank still needs a risk process.
Fraud monitoring does not rewrite authorization law
The 2026 rules add risk-based monitoring expectations. They do not mean every suspicious entry is automatically legally unauthorized.
The bank should preserve separate fields for:
- authorization status;
- fraud-monitoring result;
- false-pretenses suspicion;
- manual review decision;
- final payment disposition.
Unauthorized claims feed back into Originator monitoring
If one Originator generates unusually high unauthorized debit claims, the ODFI should not treat each return as an isolated operations item.
Authorization-quality metrics can include:
- unauthorized return rate;
- proof-of-authorization request volume;
- missing evidence rate;
- SEC-code mismatch rate;
- revoked-authorization origination attempts;
- complaints per thousand entries;
- WEB/TEL evidence failures.
This turns authorization into a monitored control framework.
15. Controls, reconciliation, reporting and real-bank operating design
Authorization should be designed as an operating capability, not a legal-document archive.
Control 1 — product eligibility
The Originator can only use SEC Codes included in its approved product profile.
A payroll-only customer should not suddenly originate TEL debits.
Control 2 — Receiver/account classification
Consumer and corporate applications should match the receiving account relationship expected for the SEC Code.
Control 3 — authorization presence
For entries requiring an authorization record, the system should confirm a valid authorization exists before release.
Control 4 — authorization state
The record must be active and effective for the payment date.
Control 5 — terms
Amount, frequency, channel and scope must be consistent with the authorization or agreement where applicable.
Control 6 — SEC-code derivation
SEC Code should be derived/validated from the actual payment and authorization characteristics.
Control 7 — evidence availability
The Originator must be able to produce proof within the required timeframe.
Control 8 — revocation synchronization
Revocation or agreement termination must propagate to schedules, templates and payment queues.
Control 9 — fraud monitoring
Authorization validity and fraud risk both need monitoring, especially under the 2026 rule changes.
Control 10 — auditability
Manual overrides should record who, why, when and what evidence supported the decision.
Authorization reconciliation
A bank can perform several useful reconciliations.
Payment-to-authorization: every relevant debit references an active authorization or corporate agreement.
Authorization-to-payment: recurring authorizations generate only expected populations.
Revocation-to-schedule: revoked authorizations have no future active payment schedule unless another valid authorization exists.
SEC-to-authorization-method: WEB payments came from WEB-eligible authorization; TEL from TEL authorization; corporate codes from corporate relationships.
Evidence-to-case: every PoA request has a matching response or open escalation.
Reporting
Operational dashboards can show:
- active authorizations by type;
- newly created/revoked authorizations;
- recurring versus standing relationships;
- SEC-code mix;
- WEB/TEL volumes;
- proof-of-authorization requests;
- overdue evidence cases;
- unauthorized return trends;
- suspected false-pretenses cases;
- originators with high exception rates.
Real-bank ownership
A practical RACI often spans:
product — defines supported applications;
legal/compliance — interprets requirements;
operations — handles evidence requests and exceptions;
fraud/risk — monitors suspicious activity;
technology — enforces state/SEC rules;
relationship/onboarding — validates Originator processes;
audit — tests evidence and control operation.
If ownership is not explicit, authorization defects tend to remain invisible until a dispute occurs.
16. End-to-end cases, BA checklist and testing
The best way to validate Chapter 9 is to walk through realistic cases.
Case 1 — recurring consumer PPD debit
A gym customer signs a recurring ACH debit authorization.
The system stores authorization ID AUTH-1001, account token, authorization version, recurring status, effective date and revocation method.
The monthly billing engine creates a debit.
Before release:
- Authorization is active.
- Account matches.
- Amount fits the agreed billing model.
- PPD is valid for the product.
- No revocation exists.
- Originator is entitled.
- Payment receives authorization lineage.
Later, the customer revokes.
The authorization state changes to REVOKED, future schedule is disabled, historical debits remain linked to the authorization version active when they were originated.
Case 2 — WEB one-time debit
A consumer pays an invoice on a merchant website.
The merchant presents clear ACH debit authorization terms. The consumer authenticates, enters/chooses the account and affirmatively accepts.
The system stores the authorization text version, acceptance timestamp, customer/session evidence and account reference.
The entry is originated as WEB.
If an RDFI later requests proof, the Originator can reconstruct exactly what the customer accepted.
Case 3 — TEL debit
A customer calls a service center to pay an overdue bill.
The agent follows the approved TEL script and obtains oral authorization. The authorization is recorded or confirmed according to the TEL requirements.
The payment engine links the recording/case evidence to the entry and uses TEL.
A generic PPD batch template must not override the SEC classification.
Case 4 — corporate CCD debit
A parent company concentration service pulls funds from a subsidiary account.
The companies have an agreement and the bank has a cash-concentration service contract.
The payment engine confirms:
- corporate Receiver classification;
- approved concentration account;
- CCD debit entitlement;
- agreement effective date;
- amount/limit;
- approver authority.
The authorization proof is the corporate agreement and bank entitlement chain rather than a consumer mandate form.
Case 5 — Standing Authorization and app-initiated Subsequent Entry
A consumer establishes a Standing Authorization.
A month later, the consumer opens the app and affirmatively instructs a $250 debit.
The system stores both the standing authority and the individual subsequent instruction.
The payment links:
Standing Authorization → Subsequent Instruction → SEC Code → ACH Entry.
Revoking the Standing Authorization later blocks new subsequent payments but does not invalidate the already initiated payment automatically.
Case 6 — proof request with missing vendor evidence
An RDFI requests proof for a disputed WEB debit.
The ODFI forwards the case to the Originator. The Originator says its payment processor captured the authorization. The processor cannot locate the version accepted by the customer.
The financial issue is now also a governance issue.
A post-incident review should ask:
- was evidence ownership defined during onboarding?
- was retention tested?
- did the ODFI monitor proof-request failures?
- should the Originator continue to use WEB origination without remediation?
BA requirement checklist
For every ACH authorization solution, ask:
Business and participant model
- Who is the Receiver?
- Consumer or corporate account?
- Who is the Originator?
- Is a third party involved?
- Is the payment credit or debit?
Authorization model
- Written, similarly authenticated, oral, corporate agreement, standing, source-document or other?
- Single, recurring or subsequent?
- What are the terms?
- How is revocation handled?
- What changes require notice/new authority?
SEC Code
- Which code is valid?
- Is it derived or user selected?
- What account/application rules validate it?
- What addenda/data format applies?
Evidence
- Where is proof stored?
- Who owns it?
- How long is it retained?
- Can it be reproduced?
- Can the ODFI retrieve it within the rule timeframe?
Operations
- How are disputes routed?
- How are proof requests tracked?
- How are revocations synchronized?
- What monitoring detects SEC mismatches or unauthorized trends?
Risk
- What fraud monitoring applies?
- How are false-pretenses concerns represented?
- What manual review is permitted?
- What happens if authorization is valid but fraud suspicion is high?
Testing catalogue
A serious Chapter 9 implementation should include at least the following tests.
PPD recurring debit — active authorization
Expected: entry accepted for origination.
PPD debit — revoked authorization
Expected: blocked before release.
WEB debit — evidence missing
Expected: origination or operational policy outcome according to product design; control alert generated.
TEL debit — wrong SEC Code PPD
Expected: SEC validation failure.
CCD debit — Receiver classified consumer
Expected: application mismatch identified.
CTX — corporate agreement expired
Expected: blocked.
Standing Authorization — valid subsequent instruction
Expected: payment created with dual lineage.
Standing Authorization — no affirmative subsequent instruction
Expected: no Subsequent Entry.
Revocation received while payment queued
Expected: authorization re-evaluated at release according to timing/process rules.
Authorization version change
Expected: old payments retain old version linkage; new payments use new version.
Proof request
Expected: evidence retrieved and case completed within applicable timeframe.
Corporate proof request
Expected: agreement/entitlement evidence retrievable.
False-pretenses alert
Expected: authorization remains represented separately from fraud suspicion.
SEC-code mapping regression
Expected: only supported consumer/corporate/channel combinations pass.
What should never happen
A production ACH authorization platform should never allow these shortcuts:
authorization = true with no evidence;
SEC = PPD because it is the default;
revocation stored only in CRM while payment schedules continue;
WEB proof stored only as a screenshot with no customer linkage;
TEL authorization with no required recording/confirmation evidence;
corporate debit enabled only because the account is a business account;
Standing Authorization treated as automatic recurring authority;
fraud-monitoring approval treated as proof of Receiver authorization.
Final practitioner summary
A strong ACH professional should be able to look at any entry and answer five questions.
1. What application is this?
That is expressed through the SEC Code.
2. Who had authority to originate it?
That comes from the Receiver authorization, corporate agreement or application-specific rule framework.
3. What evidence proves that authority?
That comes from the stored authorization/agreement and audit trail.
4. Was the authority still valid when the payment was released?
That requires lifecycle, revocation and version control.
5. Does the ACH entry actually match the authorization model?
That requires SEC-code, account, channel, amount, frequency and product validation.
When those five answers are connected, authorization stops being paperwork and becomes what it really is: a core control layer of ACH payment processing.
Authoritative references
Nacha — ACH Guide for Developers: How ACH Works
https://achdevguide.nacha.org/how-ach-works
Nacha — ACH Guide for Developers: ACH File Details and SEC Codes
https://achdevguide.nacha.org/index.php/ach-file-details
Nacha — Meaningful Modernization / Standing Authorizations and Subsequent Entries
https://www.nacha.org/rules/meaningful-modernization
Nacha — Minor Rules Topics / Subsequent Entry clarifications
https://www.nacha.org/rules/minor-rules-topics
Nacha — Importance of Compliant ACH Authorizations
https://www.nacha.org/news/importance-compliant-ach-authorizations
Nacha — WEB Proof of Authorization Industry Practices
https://www.nacha.org/system/files/2022-11/WEB_Proof_of_Authorization_Industry_Practices.pdf
Nacha — 2026 Fraud Monitoring Phase 1
https://www.nacha.org/rules/risk-management-topics-fraud-monitoring-phase-1
Nacha — 2026 Fraud Monitoring Phase 2
https://www.nacha.org/rules/risk-management-topics-fraud-monitoring-phase-2
Nacha — Credit-Push Fraud Monitoring Resource Center
https://www.nacha.org/content/credit-push-fraud-monitoring-resource-center
Nacha — Summary of Upcoming Rule Changes
https://www.nacha.org/content/summary-upcoming-rule-changes
Nacha — Banking Conventions
https://www.nacha.org/content/banking-conventions
Nacha — ACH Operations Bulletin 1-2022 / restoration of standard proof timeframes
https://www.nacha.org/news/ach-operations-bulletin-1-2022-covid-related-relief-certain-nacha-operating-rule-provisions
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.