[GNC-dev] New OFX Requirements For USAA FSB
ripngo at gmail.com
Sun Feb 7 12:00:36 EST 2021
Wow! That's dedication!
I have to admit, the same thing happened with my Credit Union (Patelco)
and I didn't have the dedication to do what you did!
Kudos to you. It's really maddening, like you say, that apparently the
only clients that our banks think have the right to download their data
are Quicken customers.
In any case, thanks for posting the "recipe" and the details of how you
got to your final success. I'm impressed!
One thing though: I would have imagined that the communication between
Quicken and your bank was encrypted, how were you able to decrypt that,
not knowing any of the keys they probably use?
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:
> They were able to determine that USAA was:
> - using a new OFX endpoint:
> - 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:
> 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
> | 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
> 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:
> <META NAME="robots" CONTENT="noindex,nofollow">
> 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
More information about the gnucash-devel