[GNC-dev] New OFX Requirements For USAA FSB

Jean L ripngo at gmail.com
Sun Feb 7 23:54:08 EST 2021

OK I get it, nothing on top of https.
Thanks for all this great info.

On 2/7/2021 7:53 PM, Scott McRae wrote:
> The encryption is all standard HTTPS (which is HTTP over TLS). It is 
> encrypted in both directions on the network. But if you are 
> terminating the TLS (a.k.a. SSL) connection, you get to see the 
> unencrypted data from both directions. This is what a 
> man-in-the-middle does.
> On Sun, Feb 7, 2021 at 7:51 PM Jean L <ripngo at gmail.com 
> <mailto:ripngo at gmail.com>> wrote:
>     Oh cool!
>     Thanks for the pointer.
>     One more question: is the ofx data encrypted on the way back to
>     your side of things? It does not look like it is since you're able
>     to download your data once you know all the parameter of the
>     "traditional" ofx query, is that right?
>     J.
>     On 2/7/2021 7:28 PM, Scott McRae wrote:
>>     I'm you want something a bit more automated, I came across
>>     mitm-proxy in searches:
>>     https://mitmproxy.org/
>>     This should take care of generating certificates
>>     automatically and actually do the forwarding, etc. You'll need to
>>     generate a CA cert for it and install that in your trusted
>>     certificates. Their docs should explain how. I didn't actually
>>     use it, since my manual method ended up working, but this sounds
>>     better suited for your use case.
>>     On Sun, Feb 7, 2021 at 7:23 PM Jean L <ripngo at gmail.com
>>     <mailto:ripngo at gmail.com>> wrote:
>>         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 :(
>>         Jean
>>         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