21–30 of 36 posts
Earlier quoted context omitted.
Basically scrape the account. Avg daily balance is probably the primary number. Low balance, high balance, NSFs, etc.
Pretty close! We're not scraping anything which I'll clarify more for the connotation that this is web scraping - it's not.
If you find this interesting you may find the work Knox is doing pretty cool - we're able to verify funds before we make payments (so there no NSFs), get and verify account numbers without asking for the user to tell us them, and verify the identity of the payor all in one step - we just have them log into their online banking (like you do with Mint or Yodlee except faster). We've never had an ACH file returned ever,…
If you find this interesting you may find the work Knox is doing pretty cool - we're able to verify funds before we make payments (so there no NSFs), get and verify account numbers without asking for the user to tell us them, and verify the identity of the payor all in one step - we just have them log into their online banking (like you do with Mint or Yodlee except faster). We've never had an ACH file returned ever,…
You should fix the lack of SSL security on thesimpledifference.com Why? iFrame SSL certificates aren't visible, and no, your VeriSign trusted doesn't count. This means users will find it offputting as you note. Why else? Someone could hijack the HTTP page and point the iframe location somewhere else where they then intercept bank details. Next knox only seems to support a limited number of banks, unlike ACH which I'm…
Please write part 3. That will be very helpful.
I have written exports from various payroll systems to produce NACHA compliant ACH files to upload to banks, every time there was a problem the bank would get back to us through the customer and we would get super weird or vague responses. In the future I am going to ask for the return codes ( https://zenpayroll.com/ach_return_codes ) listed in the article, very useful bit of info, thanks!
To understand ACH it helps to understand that it's basically electronic checks. The FRB system was (and is) the nation's clearing house for physical checks. The people who created ACH took as their model the existing system of check processing.
By the time I started, a goodly portion of inbound files came over a wire, but many (if not most) still came on magnetic tapes delivered each day by couriers. A few years earlier all files had come as magnetic tapes and (I believe) before that, punch card decks.
The biggest risk, and the thing we lived in fear of -- and I suppose they still do -- is a "delayed file." If a file cannot be processed by the promised time because of an error in the ACH system, then the receiving accounts are not credited when they are due. This results in "float" -- interest lost. This can reach into the millions, and when the Federal Reserve is at fault, they have to eat it.
The post talks a lot about rejections. In my day, the largest most complicated program was the "The Editor" which had only one job: to reject files. This beast took the form of a three inch thick green bar printout which I would remove from a hanging file folder each day. If memory serves, about 1 out of 10 lines was GO TO. I could wax on, but suffice to say, this drove me out of programming for 12 years.
When I saw this post, I had to wonder if any of the code I wrote so long ago is still running today.
No sarcasm here at all.
Please write part 3. That will be very helpful.