[GNC-dev] New OFX Requirements For USAA FSB

Jean L ripngo at gmail.com
Sun Feb 7 22:23:30 EST 2021

Wow, that's really cool. I would love to replicate that to be able to 
connect to my bank as I'm sure many would. I wonder if there would be a 
way to make that a bit easier than completely manually.
At the moment, I have a python script that logs into my bank, make the 
right clicks and downloads the OFX files. Definitely NOT robust so I 
would love to be able to go back to downloading ofx files directly.

Could you possibly write a small blurb on how to do this, from start to 
finish? That would be super useful for me. On the other hand, I'm not 
sure whether this is 100% within the law, not sure whether the DMCA has 
something to say about this or not :(


On 2/7/2021 7:06 PM, Scott McRae wrote:
> >>/So I decided to give the devil his due and temporarily got a Quicken />>/subscription and setup an SSL man-in-the-middle. />Sure, you can have a man-in-the-middle setup, but if you don't have the 
> >keys that quicken and the bank use to communicate and communications are 
> >encoded, you can't get any data from being in the middle, unless I'm 
> >missing something.
> I generated a self-signed cert and added to the trust store on my Mac OS
> keychain. I was actually able to get away with a very manual man-in-the-middle
> using an "openssl s_server" command running on 433, modifying the /etc/hosts
> file to point back to my machine, and copy-pasting the request to curl, then
> copy-pasting the response.
> On Sat, Feb 6, 2021 at 8:45 PM Scott McRae <smcrae at parax.com 
> <mailto:smcrae at parax.com>> wrote:
>     I got this working in my software with some help for the info on
>     this list. Here is a write-up:
>     USAA's changes to their OFX interface
>     -------------------------------------
>     On 2020-01-26, USAA's previous OFX interface
>     (https://service2.usaa.com/ofx/OFXServlet) stopped working. It
>     seems like they switched to a new interface through a tech
>     provider to replace their previous login method (with your website
>     credentials) to an app-specific ID and password. This is a good
>     move for security, but it was done without notice, it seems, to
>     anyone but Quicken.
>     From some internet searches, I found some people on the right
>     track to fixing this on the GNU Cash development mailing list:
>     https://lists.gnucash.org/pipermail/gnucash-devel/2021-January/045664.html
>     They were able to determine that USAA was:
>      - using a new OFX endpoint:
>     https://df3cx-services.1fsapi.com/casm/usaa/access.ofx
>      - using a new OFX Org ID: USAA Federal Savings Bank
>      - using a new OFX FID: 67811
>     Additionally, someone on the USAA forums was about to extract and
>     post the link to generate an App ID and PIN:
>     source:
>     https://communities.usaa.com/t5/Finances/USAA-Creates-Quicken-Monopoly/td-p/243850/highlight/false
>     Authorization link: https://df3cx-services.1fsapi.com/casm/usaa/enroll
>     However, with a lot of trial and error I still wasn't able to hit
>     this new endpoint successfully. So I decided to give the devil his
>     due and temporarily got a Quicken subscription and setup an SSL
>     man-in-the-middle.
>     The new OFX interface is *very* finicky, so you basically have to
>     input everything exactly the way it expects it. Here is an example
>     of an account listing query that works:
>     echo -en
>     Federal Savings
>     Bank\r\n<FID>67811\r\n</FI>\r\n<APPID>QMOFX\r\n<APPVER>2300\r\n<CLIENTUID>1955A543-B071-455E-A31E-73CC7C493D68\r\n</SONRQ>\r\n</SIGNONMSGSRQV1>\r\n<SIGNUPMSGSRQV1>\r\n<ACCTINFOTRNRQ>\r\n<TRNUID>e39add7d-2085-4504-b9ee-be37927de39c\r\n<ACCTINFORQ>\r\n<DTACCTUP>19900101\r\n</ACCTINFORQ>\r\n</ACCTINFOTRNRQ>\r\n</SIGNUPMSGSRQV1>\r\n</OFX>\r\n"
>     | curl -isS -X POST -H "Content-Type: application/x-ofx" -A
>     InetClntApp/3.0 --data-binary @-
>     https://df3cx-services.1fsapi.com/casm/usaa/access.ofx
>     Note you have to change the XXXXX and NNNNN to the App ID and PIN
>     you get from the link above.
>     Some things I've found through trial and error:
>      - The OFX elements must be separated with "\r\n". This is dumb,
>     but true. No spaces. No simple "\n". Exactly "\r\n".
>      - The APPID "QMOFX" and APPVER "QMOFX" work. Others I tried did not.
>      - The CLIENTUID "1955A543-B071-455E-A31E-73CC7C493D68" works for
>     me. It must be uppercase. This might be particular to your
>     account. If so, you can find it looking at the OFX logs from Quicken.
>      - TRNUID must be present, but an UUID will do.
>      - DTACCTUP: The value "19900101" works. The value "19700101" does
>     not. The value "19900101000000" does not.
>      - You need the "Content-Type: application/x-ofx" header
>      - You need the User-Agent "InetClntApp/3.0". This is what Quicken
>     for Mac sends.
>     It also seems their gateway will under some conditions put your IP
>     on a ban list. If you are testing, you may want to spin up an AWS
>     instance or something. When you get on it, you'll start seeing an
>     empty HTML page response, like:
>     <html>
>     <head>
>     <META NAME="robots" CONTENT="noindex,nofollow">
>     <script
>     src="/_Incapsula_Resource?SWJIYLWA=5074a744e2e3d891814e9a2dace20bd4,719d34d31c8e3a6e6fffd425f7e032f3">
>     </script>
>     <body>
>     </body></html>
>     Valid queries will work from different source IPs when this happens.
>     Thanks to Bob White on the GNU Cash list and RDD! on the USAA
>     Forums for the breadcrumbs. No thanks to USAA for swapping out
>     their functional interface with absolutely no notice or
>     documentation and pretending like Quicken users are the only
>     customers of any importance. Please just don't break our software
>     again... at least for awhile.
>     - Scott McRae

More information about the gnucash-devel mailing list