NACHA SEC codes
The Standard Entry Class code (positions 51-53 of the Batch Header) is the single most consequential field in a NACHA file. It decides which authorization rules apply, what the receiver's dispute window is, what addenda format is allowed, and whether your file goes through at all. This page covers the 12 SEC codes that NACHA treats as the canonical set — what each one does, comparisons of the ones that look alike, and the cases where only one specific code is legally allowed.
Section 1 · The full map The 12 SEC codes you'll actually see
NACHA's own reference materials — the SEC Code Detail Cards and the Origination Handbooks — treat 12 codes as the canonical set. (NACHA's detail-card set is sometimes described as "13 codes" because they print WEB Credit and WEB Debit on separate cards, but in the file format these are the same three-letter SEC code WEB — so it's 12 distinct codes.) That's the list below, grouped into four practical categories: consumer-authorized, business (B2B), check-conversion, and international. The legacy POS code is included because NACHA still publishes a detail card for it, even though most modern originators won't generate one. Click any row to jump to its detail section.
Reality check: ~95% of production traffic uses just 5 codes — PPD, CCD, WEB, TEL, and CTX. The check-conversion family (ARC/POP/BOC/RCK), CIE, and IAT cover specific operational workflows you'll only hit if you operate in those lanes.
Section 2 · Each code in detail What each SEC code actually does
Below: every code from the table above, in the same order. The five workhorse codes (PPD, CCD, WEB, TEL, CTX) get full deep-dives with format specs, gotchas, and real file examples. Specialized codes get a tight summary covering when they're used and what's distinctive.
The default SEC code for any recurring consumer transaction with paper-based authorization. Direct deposit payroll is the textbook PPD use case — and so is rent collection from a tenant who signed an authorization form, recurring gym membership debits, government benefit deposits, and most consumer subscriptions established offline.
- Receiver is a consumer (individual, not a business)
- Authorization was obtained via signed paper form or similar offline method
- Transactions are recurring or pre-scheduled
- You want the simplest, most-supported SEC code that all RDFIs accept reliably
- Authorization came from a website → use WEB
- Authorization came over the phone → use TEL
- Receiver is a business → use CCD
- You're converting a check → use ARC, POP, or BOC
Format specifics
Service Class: Typically 220 for credit-only batches (payroll), 225 for debit-only (recurring billing), or 200 for mixed.
Transaction codes allowed: 22 (checking credit), 27 (checking debit), 32 (savings credit), 37 (savings debit). Plus their prenote variants 23/28/33/38.
Addenda: 1 maximum per entry. Type code 05. Free-text 80 chars in Payment Related Information.
Individual Name field (pos 55-76 of Entry Detail): Receiver's name. Required. ASCII-only, left-justified, space-padded.
Company Entry Description (pos 54-63 of Batch Header): Free-text, but receivers see this on their bank statement — use something they'll recognize like PAYROLL or RENT .
Real file example
A payroll batch from a fictional company. The SEC code is highlighted:
The SEC code for any consumer payment where authorization happened on a website or mobile app. SaaS subscription billing, e-commerce checkout via ACH, peer-to-peer transfers initiated from an app — all WEB. NACHA imposes additional fraud-detection and account-validation requirements specifically because the authorization happens digitally.
- Consumer authorized via web form, mobile app, or chatbot
- You can produce evidence of the authorization (web session log, signed e-form) — NACHA doesn't mandate which evidence, but ODFIs typically expect timestamp, IP, and the displayed authorization text
- You're billing a SaaS subscription or recurring online service
- One-time online purchase paid via ACH (e.g. invoice paid through a portal)
- Authorization came from a signed paper form → use PPD
- Authorization came from a phone call → use TEL
- Receiver is a business → use CCD
- You haven't implemented commercially reasonable fraud detection
Format specifics
Service Class: Typically 225 (debit-only) for subscription billing, occasionally 220 for refunds, or 200 for mixed.
Transaction codes: Same set as PPD/CCD. Most WEB traffic is debits (TC 27 / 37) since it's billing.
Addenda: 1 maximum per entry. Type code 05.
Individual Name field: Receiver's name (consumer). Required, ASCII-only.
Payment Type Code (pos 77-78 of Entry, Discretionary Data): NACHA recommends R for recurring or S for single-entry, though this is not strictly enforced.
Real file example
The phone-channel sibling of WEB. Use TEL when a payment was authorized during a phone conversation — most often a one-time charge initiated when a consumer calls customer service. Common for utility bills, late-fee payments, and emergency payments where the customer can't easily get to a website.
- Authorization happened during a phone conversation (live agent or IVR)
- The call is inbound from the consumer, OR there's a pre-existing relationship (written agreement, or goods/services purchased in the last 2 years)
- You can produce the required authorization evidence — see the callouts below; requirements differ for single-entry vs. recurring
- It's a single-entry / one-off payment — TEL can carry recurring per NACHA Rules, but in practice most originators use PPD for recurring instead (see practice note below)
- The call is outbound cold telemarketing — no inbound call AND no pre-existing relationship = TEL is prohibited
- You don't have any retained authorization evidence (recording or written confirmation)
- The payment is recurring AND you don't want to comply with the stricter Reg E + dual-evidence requirements — use PPD instead
Format specifics
Service Class: Typically 225 (debit-only).
Transaction codes: Almost always 27 (checking debit) or 37 (savings debit).
Addenda: 1 maximum, type code 05.
Individual Name field (pos 55-76): Required. Consumer's name as ASCII text. 22 characters.
Same Day ACH: TEL is eligible for Same Day ACH (subject to per-entry $1M cap and ODFI cutoff times) — useful for urgent utility payments before service shutoff.
• Single-entry TEL: Originator must either make an audio recording of the oral authorization, or send the consumer a written notice confirming the authorization before the entry settles. One or the other — not both.
• Recurring TEL: Originator must comply with Reg E for preauthorized transfers, which means both an audio recording and a written copy of the authorization sent to the consumer. The dual-evidence burden is why most originators avoid recurring TEL and use PPD instead.
Either way, the evidence must be retained for 2 years from the authorization date (single) or termination/revocation (recurring).
Real file example
CIE is the inverse of normal consumer ACH: the consumer's bank originates the entry on the consumer's behalf, sending money to a biller. This is what powers traditional online banking bill-pay. Most originators don't generate CIE files — banks and bill-pay processors do. If you're a biller, you'll receive CIE credits, not send them.
Initiated by: The consumer's bank (acting as ODFI on their behalf).
Direction: Always credit — money flows from the consumer's account to the biller.
Addenda: 1 maximum. Carries the biller's account number / customer reference.
When you'd encounter it: If you operate AR for a utility, telco, or any company that accepts online bill-pay, your incoming ACH credit feed will include CIE entries.
The B2B equivalent of PPD. Use CCD when both the originator and receiver are businesses. The trade-off compared to PPD: stricter authorization requirements (you need a written agreement between the two companies), but a much shorter unauthorized return window — only 2 banking days, not 60. This is what makes CCD operationally faster for B2B workflows.
- Receiver is a business / non-consumer entity
- You have a written agreement authorizing ACH
- You want the short B2B return window (2 banking days for unauthorized)
- Single-invoice or simple cash transfer between corporate accounts
- Receiver is a consumer — use PPD/WEB/TEL
- You need multiple invoices in one payment with structured remit data → use CTX
- The receiver's account is a personal account even if the business owner uses it
Format specifics
Service Class: 220 (credit-only) for AP runs, 225 (debit-only) for collection runs, 200 for mixed.
Transaction codes allowed: Same as PPD — 22/27/32/37 and prenote variants 23/28/33/38.
Addenda: 1 maximum per entry, addenda type code 05. The 80-char Payment Related Information field is typically used for invoice number(s) or PO reference.
Receiving Company Name field (pos 55-76, 22 chars): The receiver's business name. NACHA's spec calls this field "Receiving Company Name/ID Number" specifically for CCD (PPD's equivalent at the same byte position is "Individual Name" for a consumer). Same byte position, different field semantics.
Discretionary Data (pos 77-78 of Entry): Often used for internal department/cost-center codes.
Real file example
CCD's heavyweight cousin, designed for B2B payments that need to carry structured remittance data — multiple invoices in one payment, ANSI X12 EDI segments, line-item breakdowns. The defining feature: up to 9,999 addenda records per entry, vs. CCD's hard limit of 1. If your AP department wants to send a single payment that covers 50 invoices and have it auto-reconciled on the receiver's side, CTX is how you do that in ACH.
- One payment covers multiple invoices (consolidated AP)
- You need to send structured EDI data alongside the payment (820, 835, etc.)
- Receiver's AR system auto-reconciles ACH credits with invoice IDs
- Both parties have EDI translator infrastructure set up
- You only have one invoice per payment → CCD with 1 addenda is enough
- The receiver can't process X12 EDI — many small businesses can't
- You haven't tested the EDI handoff end-to-end with the receiver
Format specifics
Service Class: Same as CCD: 220, 225, or 200.
Transaction codes: Same set as CCD — 22/27/32/37.
Entry Detail layout differs from PPD/CCD: CTX uses a different Entry Detail Record field layout. The bytes that PPD and CCD use as one continuous 22-character name field (pos 55-76) are split in CTX into:
- pos 55-58 (4 bytes): Number of Addenda Records — a 4-digit count,
0001to9999 - pos 59-74 (16 bytes): Receiving Company Name / ID Number — the receiver business name, truncated to 16 chars
- pos 75-76 (2 bytes): Reserved (blank)
Other Entry Detail positions (Identification Number at 40-54, Discretionary Data at 77-78, Addenda Record Indicator at 79, Trace Number at 80-94) are unchanged from PPD/CCD.
Addenda content: ANSI X12 segments (typically transaction sets 820 — Payment Order/Remittance Advice, or 835 — Healthcare Claim Payment).
Real file example
The most common check-conversion code. A consumer mails a paper check to a lockbox or biller (utility, credit card, mortgage), and the biller converts it to ACH at processing time instead of depositing the physical check. The check itself is destroyed after capture; the ACH entry uses the routing/account information from the MICR line.
NACHA mandate Required notice: Originator must have provided clear and conspicuous notice (typically on the bill or remittance envelope) that mailed checks may be converted to ACH, before receiving the check.
NACHA mandate Eligibility: Personal consumer checks only. Excluded: business checks, money orders, traveler's checks, cashier's checks, federal/state/local government checks, and any check over $25,000.
NACHA mandate Source document retention: Originator must retain a reproducible, legible image or copy of the front of the source document (the check) for 2 years from the settlement date of the entry, and produce it within 10 banking days when an ODFI requests it.
Return window: 60 days (R10 / R11 unauthorized), like other consumer SEC codes. Administrative returns (NSF, account closed) follow the standard 2-banking-day window.
Used at a physical point of sale: the customer hands the cashier a paper check, the cashier runs it through a check reader, the system converts it to ACH on the spot, the customer signs an ACH authorization receipt, and the void check is handed back. Common at retail registers and check-cashing-style payment terminals.
Required notice: Posted notice at point of sale + signed authorization receipt.
Eligibility: Consumer-source personal checks under $25,000. No business checks.
Distinguishing feature: Customer is physically present and signs at time of conversion. Voided check is returned.
The middle ground between ARC and POP. The customer hands a check at the register or drop box, but conversion happens later in a back office (typically end-of-day batch). The customer is notified by signage at the register; no on-the-spot signature is required. Common at retail chains where front-of-house staff aren't trained on ACH conversion.
Required notice: Conspicuous signage at the point where the check is accepted, plus a copy on the receipt.
Eligibility: Same limits as POP — personal checks under $25,000.
Workflow distinction: Conversion happens in batch later, not in real time. The voided check may or may not be returned to the customer at the register.
A previously bounced paper check, resubmitted as ACH instead of as a physical re-deposit. Strictly limited to checks that were returned for NSF (insufficient funds) or uncollected funds — not for stop-payments, account-closed, or fraud-related returns. RCK can be re-presented up to twice within 180 days.
Eligible only when: Original check was returned R01 (NSF) or R09 (uncollected funds).
Notice required: Originator must have given notice on the original transaction that bounced checks may be re-presented electronically.
Limit: Up to 2 RCK re-presentments per original check, within 180 days of the original date.
Mandatory whenever any leg of the transaction crosses the U.S. border — even if both the originating and receiving banks happen to be U.S. institutions, but funds came from or are bound for a non-U.S. financial agency. The format is fundamentally different: instead of 1 optional addenda, IAT requires 7 specific addenda records carrying originator, beneficiary, and intermediary bank information for OFAC screening.
NACHA mandate 7 mandatory addenda records. Every IAT entry must be followed by exactly 7 specific addenda records carrying Bank Secrecy Act "Travel Rule" data:
- Type 10: First IAT addenda — transaction type code, foreign payment amount, foreign trace number, receiving individual/company name
- Type 11: Originator name + street address
- Type 12: Originator city, state/province, country, postal code
- Type 13: Originating DFI name + ID + branch country code
- Type 14: Receiving DFI name + ID + branch country code
- Type 15: Receiver identification + receiver street address
- Type 16: Receiver city, state/province, country, postal code
OFAC mandate OFAC screening. RDFIs (and gateway operators on inbound IAT) are required by U.S. law — not just NACHA — to OFAC-screen IAT entries. Missing or malformed addenda records will be rejected for non-compliance.
Foreign Exchange handled outside ACH: The Entry Detail Record's amount field carries U.S. dollars. FX conversion happens at one of the gateway banks, not in the ACH network itself. The foreign-currency amount, ISO currency codes, and FX reference are carried in the batch header and Type 10 addenda.
Originally for shared POS network entries — debit-card transactions cleared through ACH between regional networks before card networks took over. NACHA still publishes a detail card for POS, so it remains in the canonical 12, but in production today it's largely supplanted by Visa, Mastercard, and the major debit networks. Don't confuse with POP: POS is card-network-related; POP is check conversion at the cashier. Different codes, different worlds.
Original use: Shared regional ATM/POS network purchases settled via ACH.
Today's reality: Most POS-style transactions clear through card networks. ACH POS appears mainly in older credit-union and regional network setups.
Common confusion: POS (card network) vs POP (check conversion) — they share three letters and "point-of-sale" semantics but are completely different codes.
Section 3 · Codes that look alike Side-by-side comparisons of the easy-to-confuse pairs
Several SEC codes overlap enough that picking between them is the actual decision you'll face in production. The four comparisons below cover the questions that come up most often.
| Dimension | CCD | CTX |
|---|---|---|
| Receiver type | Business | Business |
| Authorization | Written agreement | Written agreement (often broader trading partner agreement) |
| Unauthorized return window | 2 banking days (R29) | 2 banking days (R29) |
| Max addenda per entry | 1 | 9,999 |
| Addenda content | Free-text 80 chars (invoice ref, PO) | ANSI X12 EDI segments (820, 835, etc.) |
| Receiver-side capability | Any RDFI accepts | Receiver must have EDI translator |
| Receiver name field length | 22 chars (pos 55-76) | 16 chars (pos 59-74; pos 55-58 holds 4-digit addenda count) |
| Best for | Single invoice / single payment | Consolidated AP, multi-invoice settlements |
| Dimension | PPD | WEB |
|---|---|---|
| Receiver type | Consumer | Consumer |
| Authorization channel | Paper / signed in person | Web form / mobile app |
| Unauthorized return window | 60 days (R10 / R11) | 60 days (R10 / R11) |
| Fraud detection mandate | — | Required for WEB debits (commercially reasonable) |
| Account validation mandate | — | Required at first use, WEB debits only |
| Recurring vs single-entry | Both, leans recurring | Both, leans recurring |
| Best for | Payroll, rent, offline subscriptions | SaaS billing, e-commerce, online portals |
| Dimension | WEB | TEL |
|---|---|---|
| Authorization channel | Web form / mobile app | Phone call (live or IVR) |
| Unauthorized return window | 60 days (R10 / R11) | 60 days (R10 / R11) |
| Fraud detection mandate | Required since 2021 (WEB debits — "commercially reasonable") | No code-specific mandate — but as of 2026, large originators must run risk-based fraud monitoring across all entry types, which catches TEL too |
| Inbound caller / pre-existing relationship | Not required | Required: either inbound call from consumer OR pre-existing relationship (written agreement, or purchase within last 2 years) |
| Authorization evidence | Web session log / signed e-form (NACHA mandates "commercially reasonable", method-neutral) | Single-entry: audio recording OR written confirmation. Recurring: BOTH recording AND written authorization (Reg E) |
| Recurring vs single-entry | Both, often recurring | Allowed since 2011, but most production traffic is single-entry due to dual-evidence burden on recurring |
| Best for | SaaS subscription, e-commerce | One-off utility / late-fee phone payment |
| Dimension | ARC | POP | BOC |
|---|---|---|---|
| Where check is received | Mailed in / lockbox | At cashier (in person) | At cashier or drop box |
| When conversion happens | At lockbox processing | Real-time at the register | Later, in back office batch |
| Customer signature at conversion | No (notice on bill envelope) | Yes (signed receipt) | No (signage at register) |
| Voided check returned? | No (destroyed at lockbox) | Yes (handed back) | Sometimes (varies) |
| Personal check only? | Yes | Yes | Yes |
| Max amount | $25,000 | $25,000 | $25,000 |
| Best for | Utility / credit card billing | Retail with trained POS staff | Retail without trained POS staff |
Section 4 · Cases where only one code is allowed Scenarios where the SEC code is forced
Sometimes you don't have a choice — the situation forces a specific SEC code, and using anything else is either a NACHA rule violation or guaranteed to be returned. The list below is the most common forced-pick scenarios.