Where Banking APIs Fall Short
blog.svapnil.com
Where Banking APIs Fall Short
1–10 of 12 posts
Re: Where Banking APIs Fall Short
#2Even HL7 which is used for healthcare communication is still very often communicated over file drops as well. Honestly it has some great advantages in terms of simplicity. Need to reprocess a file? Put it in the folder. Fail to process? Move it to a different folder for later viewing. The biggest issue is just having good SFTP server and client solutions that are scalable on multiple platforms.
Re: Where Banking APIs Fall Short
#3Even HL7 which is used for healthcare communication is still very often communicated over file drops as well. Honestly it has some great advantages in terms of simplicity. Need to reprocess a file? Put it in the folder. Fail to process? Move it to a different folder for later viewing. The biggest issue is just having good SFTP server and client solutions that are scalable on multiple platforms.
I never knew about HL7, thanks for sharing.
I agree that simplicity and open standards will win. SFTP is straightforward and has worked well in the past. In banking and finance, SFTP is what powers most programmatic corporate banking. Eventually, I think we'll see SFTP and message queues (like SQS) used more often as processing speeds up. I believe message queues are what powers much of real time payment processing already (https://news.ycombinator.com/item?id=36805571)
Re: Where Banking APIs Fall Short
#4Even HL7 which is used for healthcare communication is still very often communicated over file drops as well. Honestly it has some great advantages in terms of simplicity. Need to reprocess a file? Put it in the folder. Fail to process? Move it to a different folder for later viewing. The biggest issue is just having good SFTP server and client solutions that are scalable on multiple platforms.
I never knew about HL7, thanks for sharing. I agree that simplicity and open standards will win. SFTP is straightforward and has worked well in the past. In banking and finance, SFTP is what powers most programmatic corporate banking. Eventually, I think we'll see SFTP and message queues (like SQS) used more often as processing speeds up. I believe message queues are what powers much of real time payment processing a…
Another approach is to treat it as a document exchange process that is done over REST or RPC. Message queues are attractive though in that they are easily bidirectional.
Re: Where Banking APIs Fall Short
#5[deleted]
Re: Where Banking APIs Fall Short
#6> The future doesn’t look like an API, it looks like better and better files.
Would be curious what the author thinks of initiatives like Open Banking, which don't seem to be a big topic in the US, but are in the EU and Canada at the moment.
My expectation is that banks should be abstracting away the 'under the hood' part, and so the future would look like an API.
Re: Where Banking APIs Fall Short
#7Differences between files and REST apis:
- files get persisted to disk by default. Usually we don't save every rest result to disk (though obviously, you could)
- files tend not to be processed at request time, but rather the directory acts as a queue. Usually with rest, we try to process things at request time until stuff gets too slow. Files always decouple
- multiple transports are the norm: SFTP, SMTP, etc. doesn't matter since it's not going to be processed at request time, but async. Think of "dropping it into a directory" as stripping off the transport layer the same way your web framework and reverse proxy abstract away http 2/3 for you.
- formats: much more variety than json everything. Back in the day, people liked to write custom parsers for everything. Nowadays, we like to let json be the bytes to in-memory data structure, and programmers recurse over that structure rather than spending their time ensuring their parser isn't ambiguous
Re: Where Banking APIs Fall Short
#8> The future doesn’t look like an API, it looks like better and better files. Would be curious what the author thinks of initiatives like Open Banking, which don't seem to be a big topic in the US, but are in the EU and Canada at the moment. My expectation is that banks should be abstracting away the 'under the hood' part, and so the future would look like an API.
Open Banking imo === the ISO20022 standard. It already is an "API," just in a format that most web developers aren't used to
Re: Where Banking APIs Fall Short
#9Differences between files and REST apis: - files get persisted to disk by default. Usually we don't save every rest result to disk (though obviously, you could) - files tend not to be processed at request time, but rather the directory acts as a queue. Usually with rest, we try to process things at request time until stuff gets too slow. Files always decouple - multiple transports are the norm: SFTP, SMTP, etc. doesn…
Thanks for sharing habitue
It's true that REST APIs operate under the assumption of processing at request time, while not the case with files. That's what makes Bank REST APIs so tricky - processing doesn't ever actually occur at request time.
There are so many crazy formats that are supported. Simpler is better imo
Re: Where Banking APIs Fall Short
#10Batch files have been used forever (since mainframes), and I get suspicious when someone implies that APIs are the “normal” way to do things. It makes me think they don’t have enough experience outside of the app development bubble.
Files definitely have limitations (they’re almost always a single table of data—it’s hard to do data structures), and that seems to be driven by the need for someone in the chain the be able to open it in Excel.