[GNC-dev] New OFX Requirements For USAA FSB

Mon Feb 8 01:08:22 EST 2021

Overall I can confirm that this approach works, I have gotten both 
account lists and transactions. Two details on this:
" - TRNUID must be present, but an UUID will do."   More specifically, 
it seems it must be a UUID. Aqbanking/Gnucash create a date based ID, 
and this fails (the far server actually returns a Java.IO error over it).
"The CLIENTUID "1955A543-B071-455E-A31E-73CC7C493D68" works for me" 
This worked for me too, and no other values did. Any other value I tried 
returned a message telling me to go to 
https://df3cx-services.1fsapi.com/casm/usaa/enroll. It's possible that 
this is a value identifying the client program itself, but since it sent 
me a message asking me to enroll it seems like it could also be an 
identifier for the member. It is not immediately clear to me how the 
client program is intended to get this clientuid value during the 
enrollment process - I do hope it is not through a back channel 
USAA-Quicken connection. Did your wireshark capture reveal anything 
about how Quicken obtained the clientuid?
-Randy

On 2/6/2021 8:45 PM, Scott McRae 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
 > 
"OFXHEADER:100\r\nDATA:OFXSGML\r\nVERSION:103\r\nSECURITY:NONE\r\nENCODING:USASCII\r\nCHARSET:NONE\r\nCOMPRESSION:NONE\r\nOLDFILEUID:NONE\r\nNEWFILEUID:NONE\r\n\r\n<OFX>\r\n<SIGNONMSGSRQV1>\r\n<SONRQ>\r\n<DTCLIENT>20210207031942\r\n<USERID>XXXXX\r\n<USERPASS>NNNNN\r\n<LANGUAGE>ENG\r\n<FI>\r\n<ORG>USAA
 > 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
 > _______________________________________________
 > gnucash-devel mailing list
 > gnucash-devel at gnucash.org
 > https://lists.gnucash.org/mailman/listinfo/gnucash-devel