NAK-but-no-ACK is apparently a super common pattern in enterprise (both internal and between parties.)

I have no idea why it is and why people are so resistant to adopting ACKs.

Why it's there in the first place is fairly excusable. It (at least) halves the number of datagrams. Why people still resist it I'm not so sure about.

But on the other hand, it's a complicated architectural decision. US military wants absolutely reliable communications? They invent TCP which relies a lot on acks. Swedish telecom company wants fast and absolutely reliable communicating systems? Cue throw hands in air with a "there's no guarantees even with socks so better to simply never assume your message arrived and instead focus on detecting anomalous behaviour." They invent Erlang where there are no acks for messages.

Yeah there are no acks. It sucks.

The lack of acks is why most companies receiving money through ACH will "season" the transactions for a set amount of time. Most of the returns occur in the first 3 business days so most seasoning periods are just around that long. The reality is you can receive a reject up until (I believe) 60 days after the transaction date. I've seen a lot of companies be a little smarter here and reduce the seasoning times for repeat users using the same source bank account. It is a fascinating system to work with every day. Wire transfers are their own bundles of fun too.

Now I finally know why my credit-union (which serves the high-technology industry exclusively) told me that they couldn't put a hold or otherwise segregate any cheques I deposit until they've cleared... because they have no way of knowing when/if they've cleared!

It's 60 days, + some possibility of up to 2 extra days at the end for Fed Reserve holidays, and then in cases of outright fraud, occasionally banks will ignore the rules and return stuff later than that.