I'm currently working on an application for a un-named organisation. As part of this, I need to export files for processing in the Australian defacto standard for Electronic Funds Transfer (EFT) files - the ABA format.
I'm using BizTalk of course, and it can handle this weird format, however all I had was the sample file, which for a fixed width flat file is not great.
I found the format documented here: http://ddkonline.blogspot.com/2009/01/aba-bank-payment-file-format-australian.html
Apparently the banks have all agreed on this format, which is firstly Ancient in origin and format, and design Highlighting that it’s a flat file, of fixed field lengths..
If this was re-factored into a XML format, it would be much easier to generate, highly flexible, and they could expose an interface, via a simple web service to accept this format. All authentication could be done via a secure https web service, with encryption on the web service.
Let’s understand that this is used to effect payments from a company’s bank account to individuals, this is highly sensitive and needs to be secured.
This format of this file is NOT encrypted in anyway; it is open, readable, and modifiable. There are no check digits, no certificate of authentication or any of the modern features you would expect in such a file.
By Exposing a WCF endpoint, which had authentication via certificate, using an https/transport encryption/security would handle some of this requirement; the rest is in the detail of the message itself.
Currently what happens is we output this file to the file system, and then someone picks it up... and processes it...
If a WCF or web service endpoint was open by the bank, we could securely communicate with this, and send the payment file, someone could log onto their secure interface and approve the transfers still, however there would be zero chance of someone modifying this file before it got there....
Before we got involved, this was just popped onto the file system somewhere, generated via a different method…
I am not one to mess around when it comes to security, and this smells to me. The banks need to provide an interface. I’ll happily build it, securely and flexible enough for all platforms to communicate with it.
Subscribe to:
Post Comments (Atom)
3 comments:
We have basically the same thing in the US, called a NACHA file:
http://geekswithblogs.net/bosuch/archive/2011/04/21/biztalk-using-the-flat-file-mapping-wizard-to-map-a.aspx
Not only do we just throw the file over the fence and hope it processes properly, we have to wait an indeterminate amount of time to get confirmations back.... in a similar fixed-field flat file.
I'd love to be able to submit it securly, and remove the real possibility of somone modifying it, it's HIGHLY insecure. I will not mention the name of the organisation because ALL organisations use this standard format :( It would take somone 5 minutes to add an addional, legit looking payment. I have no access to the file and do not want any, but other do....
I think your blog is very powerfull to me. We have hope that u can keep up the good job. Will u please take a look at our page also?
Aba File Format
Post a Comment