SEC Codes for ACH Payments

Introduction to SEC Codes

Standard Entry Class (SEC) codes are three-letter codes that describe how a payment was authorized by the consumer or business receiving an ACH transaction. SEC codes are defined and maintained by NACHA, the governing body for the ACH network. Every ACH transaction requires a SEC code--it is not optional.

Understanding SEC codes is essential for anyone processing ACH payments because the code determines the authorization requirements, return liabilities, and compliance obligations. Using the wrong SEC code can result in ACH returns, regulatory penalties, and increased liability for unauthorized transactions.

Why SEC Codes Matter

SEC codes serve several critical functions in the ACH ecosystem:

• Authorization proof: They communicate how the transaction was authorized, determining the level of proof required if a dispute arises
• Processing guidance: They help receiving banks apply appropriate handling procedures
• Compliance tracking: They enable NACHA to enforce authorization rules across the network
• Liability determination: The wrong code can transform a legitimate transaction into an unauthorized debit

Consumer-Focused SEC Codes

Consumer-oriented SEC codes apply to transactions involving individual (natural person) account holders. These codes are designed for consumer banking relationships and typically have more stringent authorization requirements.

PPD (Prearranged Payment and Deposit Entry)

PPD is the most common SEC code for consumer transactions. It covers:

• Single or recurring credit transactions (payroll, dividends, refunds)
• Single or recurring debit transactions (subscriptions, bill payments)
• Authorization: Written authorization or similarly authenticated consent for debits; oral authorization permitted for credits

PPD is ideal for subscription businesses, utility companies, and organizations with recurring consumer payments where written agreements are obtained.

WEB (Internet-Initiated/Mobile Entry)

WEB handles consumer ACH transactions authorized through secure digital channels:

• Single-entry and recurring debit transactions
• Credit transactions from consumer to consumer or consumer to merchant
• Authorization: Must occur through a secure (minimum 128-bit encryption) internet or mobile session

WEB is essential for any business accepting ACH payments through a website or mobile application with online authorization. This code is fundamental to modern payment integration implementations.

TEL (Telephone-Initiated Entry)

TEL covers consumer debit transactions authorized orally over the telephone:

• Single-entry and recurring debit transactions
• Authorization: Oral authorization with either recorded consent OR written confirmation before initiating payment

TEL authorizations are common in industries where phone-based payment collection is standard, such as insurance premiums and membership services.

Other Consumer Codes

• ARC (Accounts Receivable Entry): Single debit entries for check conversion via mail, in-person, or dropbox with written notice
• BOC (Back Office Conversion Entry): Single debit entries for checks processed through back-office conversion
• POS (Point of Sale Entry): Debit card transactions processed through the ACH network at retail locations
• RCK (Re-presented Check Entry): Checks returned NSF and re-presented electronically with security measures
• CIE (Customer Initiated Entry): Consumer-initiated credit entries (credit push to merchant, typically for bill pay services)

Business and Commercial SEC Codes

Business-focused SEC codes apply to transactions between corporate entities, government agencies, and other non-consumer accounts. These codes have different authorization requirements reflecting the B2B nature of the transactions.

CCD (Corporate Credit or Debit Entry)

CCD is the standard SEC code for business-to-business ACH transactions:

• Single-entry and recurring transfers for non-consumer accounts
• Corporate cash concentration and disbursement transactions
• Payments between unrelated business entities
• Authorization: Agreement between originator and receiver; web-based CCD transactions require WEB-level authorization

CCD is the default choice for standard commercial payments between businesses. When combined with bank transfer capabilities, CCD enables efficient B2B payment flows.

CTX (Corporate Trade Exchange)

CTX facilitates complex B2B payments with enhanced data capabilities:

• Single-entry and recurring credit and debit transactions
• Enhanced remittance data transmission
• High-volume commercial payments requiring detailed payment information
• Use cases: Large-scale vendor payments, complex supply chain payments, B2B transactions needing detailed invoice data

CTX is designed for organizations requiring detailed payment information alongside the transaction, such as large enterprises with sophisticated accounts payable systems.

Specialized and Government SEC Codes

Several SEC codes serve specialized purposes or are restricted to specific use cases:

IAT (International ACH Transaction)

Handles cross-border ACH payments involving institutions outside the United States:

• Transactions where originator or receiver is outside US territorial jurisdiction
• Specific documentation and compliance requirements
• Not generally available--implemented only for specific merchants with regulatory approvals

DNE (Death Notification Entry)

Restricted to federal government agencies:

• Non-monetary entry notifying financial institutions of a government benefit recipient's death
• Not available for general commercial use

ENR (Automated Enrollment Entry)

Enables non-monetary entries for ACH enrollment purposes:

• Used by federal government agencies and financial institution partners
• Establishes or modifies ACH service relationships

COR (Notification of Change)

Used for operational communication between financial institutions:

• Notifies originators about necessary corrections to account information
• Refuses entries that cannot be processed
• Non-monetary entry for administrative purposes

Choosing the Right SEC Code

Selecting the appropriate SEC code requires evaluating several factors. The decision impacts compliance obligations, authorization requirements, and potential liability.

Decision Framework

When choosing a SEC code, consider these factors in order:

1. Account Type: Is the recipient a consumer or non-consumer (business, government)?

• Consumer: PPD, WEB, TEL, ARC, BOC, POS, RCK, CIE
• Business: CCD, CTX

2. Transaction Direction: Credit (push) or debit (pull)?

• Credit only: PPD (credits), CIE
• Debit only: ARC, BOC, POS, RCK, TEL
• Both: PPD, WEB, CCD, CTX

3. Authorization Channel: How was payment authorized?

• Written agreement: PPD, ARC, BOC
• Secure internet/mobile: WEB
• Telephone: TEL (with recording requirement)
• Corporate agreement: CCD, CTX

4. Recurring vs. Single: Does customer authorize multiple payments or one-time?

• All codes support recurring except ARC, BOC, POS, RCK, CIE

Common Scenarios

Authorization Requirements by SEC Code

The authorization requirements associated with each SEC code are critical for compliance. Understanding these requirements helps design proper authorization workflows and maintain correct documentation.

Written Authorization Requirements

Several SEC codes require written authorization:

Authorization Evidence Requirements

Beyond obtaining authorization, originators must provide evidence if challenged:

• WEB transactions: Secure session log showing customer completed authorization, including authentication method
• TEL transactions: Recording of oral authorization OR written confirmation from customer
• PPD transactions: Written agreement or electronic signature captured at enrollment

Agreement vs. Authorization

NACHA distinguishes between "agreement" and "authorization":

• Authorization: Explicit permission to debit a specific account with knowledge of amount and timing
• Agreement: Broader business relationship including payment terms

For consumer debits, the stronger "authorization" standard applies. For business accounts, "agreement" between corporate entities may suffice depending on the SEC code.

Integration with Payment Platforms

When building payment infrastructure that handles ACH transactions, SEC code handling must be integrated throughout the system architecture. Proper implementation requires careful attention to validation, error handling, and compliance monitoring to prevent costly mistakes.

API Design Considerations

Payment APIs should expose SEC code selection in a way that prevents errors:

• Pre-define valid SEC codes: Limit selection to appropriate codes for account type
• Validate against authorization method: Reject mismatched combinations (e.g., TEL for non-telephone authorization)
• Require authorization evidence: Link transactions to supporting documentation
• Audit trail logging: Record SEC code selection rationale for compliance reviews

Implementing secure payment infrastructure requires expertise in both web development best practices and compliance requirements. Organizations building ACH capabilities benefit from working with experienced development teams who understand the nuances of NACHA regulations.

Error Handling

Proper error handling prevents SEC code violations:

// Validation rules:
- Consumer accounts cannot use CCD or CTX
- TEL requires telephone authorization with documented evidence
- WEB requires web/online authorization with session evidence
- PPD for debits requires written authorization documentation

Common Implementation Mistakes

Avoid these frequent errors:

• PPD for phone-authorized transactions: PPD requires written authorization, not oral--TEL is required
• WEB without secure sessions: WEB authorizations must occur through encrypted sessions
• Failing to record TEL authorizations: Verbal authorizations require recording or written follow-up
• Using business codes for consumer accounts: CCD and CTX are for non-consumer accounts only
• Forgetting recurring transaction requirements: Some codes have specific rules for recurring transactions

Compliance Monitoring

Establish ongoing monitoring to identify potential violations:

• Periodic audits: Review sample transactions to verify SEC code accuracy
• Authorization evidence checks: Confirm supporting documentation exists for all transactions
• Return analysis: Track ACH returns by SEC code to identify patterns
• Staff training: Ensure operations staff understand SEC code requirements

SEC codes work alongside fraud prevention measures to create secure payment experiences for both merchants and customers. Combining robust SEC code implementation with comprehensive AI automation for monitoring can help detect anomalies before they become compliance issues.

Summary

SEC codes are a fundamental component of ACH transaction processing that determines authorization requirements, compliance obligations, and potential liability. The 13 NACHA-defined SEC codes cover different transaction types, account categories, and authorization channels.

Key takeaways:

• SEC codes are mandatory for every ACH transaction
• Consumer transactions typically use PPD, WEB, or TEL depending on authorization channel
• Business transactions use CCD (standard) or CTX (enhanced data)
• Authorization evidence requirements vary by SEC code
• Proper SEC code selection protects against liability and compliance issues
• Implement validation in payment systems to prevent errors

Understanding the nuances of each code--and selecting the correct one for each transaction--is essential for maintaining ACH compliance and building reliable payment infrastructure.

Sources

1. Modern Treasury - ACH SEC Codes
2. Cross River - SEC Codes Documentation