4 ms·
I thought ACH was negative-confirmation-only, and a "clawback" is really just a delayed "nope" message instead of revoking or undoing a previously issued "ok" m
by DaiPlusPlus 5y ago
I thought ACH was negative-confirmation-only, and a "clawback" is really just a delayed "nope" message instead of revoking or undoing a previously issued "ok" message, simply because there is no "ok" message.
How on earth was ACH's design approved in the first place? It violates practically every principle of good transactional system design.
- aaomidi 5y agoIt's decades old.
- woodruffw 5y ago> a "clawback" is really just a delayed "nope" message instead of revoking or undoing a previously issued "ok" message, simply because there is no "ok" message. That's actually not a clawback in ACH parlance: that's just a transaction rejection, which causes the original transaction to "bounce" and enter a remediation process. Clawbacks are done via "return records", which can be issued separately of any transaction records. Clawbacks, in turn, can be dishonored and countermanded by the RDFI. I wrote a short summary of the different rules here[1]. > How on earth was ACH's design approved in the first place? It violates practically every principle of good transactional system design. ACH's design comes from the 1960s. It was designed for a time when the average American used their physical checkbook to pay for everyday items, and there was no reliable (non-military) nationwide computer network. Its design looks bad because it's optimized for forces that are currently mostly irrelevant, but used to be common: tens of thousands of tellers filing physical paper, smudged checks, typos by secretaries, delays in the mail network, the cost of long-distance calls, &c. They probably didn't even have a sound notion of a "transaction" in the ACID sense, given that Jim Gray didn't develop that particular paradigm until the 1970s. ACH's flexibility and complexity make it look staid and antiquated compared to modern settlement systems, but it's all there for a good (historical) reason. [1]: https://blog.yossarian.net/2019/12/25/A-shallow-dive-into-the-American-banking-system https://blog.yossarian.net/2019/12/25/A-shallow-dive-into-th...
- DaiPlusPlus 5y agoBut why didn't they improve it at all during the past 50 years?
- woodruffw 5y agoThey've tried! ACH has been somewhat modernized over the decades, in the form of compliance and in-protocol changes (faster turnarounds, additional transaction codes for online transactions and different cardholder verification methods). The Fed has also been working on a modern replacement to ACH for at least a decade, and is planning on performing an initial release in 2023[1]. But as for why it's taken so long: banking in the US is, for various reasons, significantly more complicated than banking in most other countries. The US has thousands of FDIC-insured banks and credit unions, each of which operates under a patchwork of municipal, state, and federal regulations. Banks are (mostly) required to honor each other's checks and transactions which means that, in the worst case, there's a total graph of all ~10,000 banks and credit unions serving as both ODFIs and RDFIs[2]. Transaction failures between any two nodes in that graph are a possible compliance failure, so any common mechanism is both a lowest common denominator and resists any modernization or other changes than can cause disruption. [1]: https://www.federalreserve.gov/paymentsystems/fednow_about.htm https://www.federalreserve.gov/paymentsystems/fednow_about.h... [2]: It's actually simpler than this, since the ACH clearinghouses serve as a central resolution and dispatch service for all ODFIs and RDFIs. But each O/RDFI still has to interpret the ACH record(s) they receive, so there's still extraordinary inertia against any changes.