Senft Payments

Blog

“AI forward,” “AI native,” and “agentic”

By Zach Senft4 min read
Originally published on LinkedIn

Someone drops a buzzword, and you think it’s above your head, that it’s for the tech giants of the world. I think the opposite, and I’ve seen it firsthand. Investing in solutions that are measurable and provide real-world impact is how you stay ahead.

I was deep into Plaid’s Signal product recently, and was shocked to see how different ML configurations affect charge behavior. Plaid Signal boils down to an AI/ML product that scores ACH transactions for return risk. It allows you to configure “rulesets” that dictate what happens at varying risk profiles and transactions.

Why ACH return risk matters

For businesses heavy on ACH payments, this matters. ACH returns are expensive, and scale rapidly. That steady flow of returns you’re seeing is like watching revenue quietly get revised down after the fact, like a 2025 jobs report.

Plaid Signal scores on two axes: return risk from the bank’s side (NSF, closed account) and return risk from the customer’s side (unauthorized dispute). Each comes back as both a raw score and a risk tier. A tier is a compressed signal. It tells you how risky, not why, and not what the risk actually costs you if it materializes.

The ruleset—not the model—makes the business decision

An interesting example I saw recently: two $69 subscription charges, evaluated separately, landed in the same risk tier on both axes. Tier 5 on bank-initiated risk, tier 3 on customer-initiated risk. So: same price, same tier, same result?

  • Transaction 1: ACCEPT
  • Transaction 2: REROUTE

The model didn’t do this; the ruleset did. That’s the point of Signal Rules: it’s a no-code layer that turns a risk tier into a business decision. Two businesses—or two configurations of the same business—can point that layer at identical risk and land somewhere completely different. Most on Plaid Signal accept the defaults. Not you, though; you know your customers’ behavior better than a generic rule does.

The cost of getting the threshold wrong

ACH, like I mentioned, is slower than card, tied directly to a bank account rather than a card network, with none of the chargeback tooling built around cards. When an ACH transaction returns, it isn’t a quick reversal. It’s a return code, re-presentment cycle, and, for unauthorized-debit returns, a dispute window that can run up to 60 days.

So what a return in that window actually costs you:

  • Fees.
  • Re-presentment attempts.
  • Revenue that you already recognized and now have to claw back.

The tricky part is that number can be wrong in each direction. Reroute too aggressively and you lose customers to friction; accept too loosely and returns eat away at your margin.

Generic ruleset configuration does not fix this for you. That threshold is specific to your return-fee structure, your customer base, and how much friction your product can absorb before people churn. That’s why it’s important to get this right.

Businesses running significant ACH volume are exactly who have the most to gain from doing that math properly—and the data to do it already sits on their payment processor.

Ready to put this to work?

Start with the payment evidence, processor configuration, and customer journey already in place before deciding what to optimize.