[GNC-dev] New OFX Requirements For USAA FSB
Cory Fazzini
cfazzini at gmail.com
Mon Feb 8 01:35:31 EST 2021
I extracted the Client ID from the enroll URL. After entering USAA
credentials, the page is redirected to
https://www.usaa.com/inet/ent_oauth_consent/authorize?0&client_id=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx&....
. I used that client_id as my clientuid. I received unauthoried message
using the clientuid posted. It would seem there may be a link between your
account and this clientuid.
I was also able to get ofxtools to work with only configuration changes. (
https://github.com/csingley/ofxtools) I used the latest MASTER branch from
Github. Configuration file is set up as this:
[USAA-NEW]
url = https://df3cx-services.1fsapi.com/casm/usaa/access.ofx
clientuid = xxxxxxxx-xxxx-xxxx-xxxxx-xxxxxxx
org = USAA Federal Savings Bank
fid = 67811
bankid = 314074269
user = xxxxxxxxx
password = xxxxxxxx
appver = 2300
version = 103
unclosedelements = true
appid = QMOFX
pretty = true
The service is picky about the date of the DTACCTUP as previously noted. It
needed to be 19900101 though the date format ofxtools generates is
"19900101000000.000[+0:UTC]", and that was fine . This
successfully returned account information using the command:
"ofxget acctinfo --dtacctup 19900101 USAA-NEW"
Cory
On Mon, Feb 8, 2021 at 1:09 AM Randy <rsjdev314 at gmail.com> wrote:
> 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
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
--
Cory Fazzini
More information about the gnucash-devel
mailing list