Smackdown Series: Unauthorized Cage Match with Host Joe Casali

Wrestling Payments Podcast: Season 3 - Episode 11

In this episode of Wrestling Payments, host Joseph Casali continues his three-part NACHA SmackDown series, taking listeners inside the high-stakes world of ACH rules violations. Through compelling real-world cases, Joseph reveals the consequences when financial institutions fail to follow proper authorization procedures.

The episode examines Steward Bank's repeated failures to provide valid authorization proof, resulting in escalating fines from warnings to $7,500. Joseph also explores O'Leary Bank's improper SEC code use, demonstrating critical compliance errors that payment professionals must avoid.

"These are really places to learn how the rules apply," Joseph explains. "Look what happened here. This went wrong, and they got fined for it. It's a really good way to learn how the rules work."

While emphasizing that NACHA's enforcement process doesn't recover funds for affected parties, Joseph provides valuable insights for operations managers and directors responsible for ACH compliance.

Host-at-a-Glance

💡 Name: Joseph Casali

💡 What they do: Executive Vice President of NEACH

💡 Company: NEACH & NEACH Payments Group (NPG)

💡 Where to find him: LinkedIn

Key Insights:

The Enforcement Process Protects the Network, Not Individual Cases

NACHA's enforcement process exists to uphold system integrity, not recover funds for affected parties. The process identifies rule-breakers and imposes fines to discourage future violations, but consumers must look elsewhere for recovery. Understanding this distinction is crucial for banking professionals managing payment operations—rules enforcement serves as a deterrent while arbitration offers a path for financial recovery. This separation of powers helps maintain ACH Network quality while giving institutions multiple ways to address unauthorized transactions.

Authorization Type Must Match the SEC Code

SEC codes must align with the authorization type obtained from customers—a critical compliance point for operations managers. Converting a check into a WEB debit constitutes an automatic rules violation because the authorization types differ fundamentally. Payment professionals must understand that each SEC code requires its distinct authorization format. This knowledge helps institutions avoid costly violations while ensuring proper payment processing across different channels.

Progressive Enforcement Drives Compliance

NACHA's enforcement panel uses progressively increasing penalties to encourage compliance, starting with warnings before moving to monetary fines. For payment professionals, this highlights the importance of addressing issues immediately rather than ignoring them.

 The panel's willingness to impose recurring monthly fines for persistent violators underscores NACHA's commitment to maintaining network integrity.

Proper Documentation Prevents Costly Violations

Under NACHA rules, the obligation to provide valid proof of authorization within 10 banking days is non-negotiable. Financial institutions must maintain organized, accessible records and ensure staff understand how to respond properly to authorization requests.

Both cases highlight the importance of having knowledgeable staff (ideally AAP-certified) who can identify proper authorization formats and requirements. Operations managers should implement procedures ensuring authorization documentation matches receiver information exactly, as mismatches invalidate the proof and trigger violations.

Episode Highlights:

The Purpose of Rules Enforcement (00:01:00)

Joseph starts the episode by clarifying that NACHA's enforcement process focuses on punishing rule violations rather than recovering funds. He explains that while the process helps maintain network integrity by identifying and fining violators, it doesn't directly help consumers get their money back.

"This is the NACHA Rules enforcement process. This process punishes, finds potentially the bad guys in the ACH Network. It finds them, it doesn't get your money back. It doesn't stop them necessarily from doing it. They would be silly to do it, as you'll see from our first case."

The Steward Bank Saga Begins (00:04:00)

Joseph outlines how Cutler Bank (RDFI) requested proof of authorization from Steward Bank (ODFI) for a consumer who reported an unauthorized transaction outside the return timeframe. Despite multiple faxed and emailed requests, Steward Bank failed to respond, leading Cutler Bank to file a rules violation.

"Several requests for proof of authorization or permission to return were faxed and emailed without response back from Steward Bank. After not receiving any response from Steward Bank, Cutler Bank filed a rules violation. Good move, good move Cutler Bank. I encourage folks in the same situation to do the same thing. It will not get your money back, but it will get their attention."

Escalating Penalties for Repeat Offenders (00:09:00)

The episode reveals how Steward Bank's continued failures led to progressively higher fines. Joseph explains the fine structure for repeat violations, showing how ignoring compliance issues can lead to increasingly severe financial consequences.

"The first recurrence is a thousand-dollar fine, which they received. They received a second recurrence, which was $2,500. They received a third recurrence, which was $5,000. The fourth recurrence is a Class 2 violation, and in this case, they have as the latest update the most recent violation resulting in an ACH rules enforcement panel imposing a fine of $7,500. It's pretty evident here that Steward Bank isn't taking a lot of actions to resolve this issue."

Check Conversion Gone Wrong (00:14:00)

Joseph explores the second case involving O'Leary Bank, where a check was improperly processed as a WEB debit. He explains the fundamental rules around check conversion and why using the wrong SEC code constitutes a serious violation.

"A check cannot be converted into a WEB. It was from a different company name. The authorization doesn't carry over to a different company. None of this is good. The rules around check conversion are, you can convert it to an ARC, a BOC, not a POP. It is never, ever a WEB. A check cannot be converted into a WEB."