I'm interested in downloading my transactions from Chase without using a third party such as Mint, Quicken, Yodlee, Plaid, and so on. I don't trust third parties with handling my data, which is why I want to do it myself.
Works as of 1/8/18
Summary
Chase uses OFX to support programmatic interactions with its financial data. It does so somewhat reluctantly however, as this fact isn't widely advertised nor well documented - banks would rather have you use their products directly, rather than go to third parties. That being said, support for desktop products like Quicken still exists, and so one method is to spoof yourself as a desktop product (the other options are to use a third party service or use a screen scraper). Obviously this solution is completely at the mercy of Chase's whims, and as a discouraged access pattern this is not robust. But you're still reading, so let's do this!
Solution
Set up your account to accept connections from Desktop apps
Account > Profile & Settings > Manage Account Security > Desktop apps > Click enable
Generate a Client UID. Chase will use this to verify that the OFX requests it's receiving are intended.
Go to https://www.uuidgenerator.net/ and generate a UID.
Use ofx-ba-tfb.py to POST the following to https://ofx.chase.com. Comments begin with a # sign, do not include them.
Headers:
OFXHEADER:100
DATA:OFXSGML
VERSION:102
SECURITY:NONE
ENCODING:USASCII
CHARSET:1252
COMPRESSION:NONE
OLDFILEUID:NONE
NEWFILEUID:{Insert random alphanumeric string}
Payload:
<OFX>
<SIGNONMSGSRQV1>
<SONRQ>
<DTCLIENT>20180108012004
<USERID>{Insert user id}
<USERPASS>{Insert password}
<LANGUAGE>ENG
<FI>
<ORG>B1 # Comes from ofxhome.com
<FID>10898
</FI>
<APPID>QWIN
<APPVER>1800
<CLIENTUID>{Insert random alphanumeric string}
</SONRQ>
</SIGNONMSGSRQV1>
<CREDITCARDMSGSRQV1>
<CCSTMTTRNRQ>
<TRNUID>{Insert random alphanumeric string}
<CLTCOOKIE>4
<CCSTMTRQ>
<CCACCTFROM>
<ACCTID>{Insert account id here}
</CCACCTFROM>
<INCTRAN>
<DTSTART>20171208
<INCLUDE>Y
</INCTRAN>
</CCSTMTRQ>
</CCSTMTTRNRQ>
</CREDITCARDMSGSRQV1>
</OFX>
Verify the request
You will get a response that says,
"Please verify your identity within the next 7 days. Using your desktop computer, go to your bank's website and visit the Secure Message Center for instructions." After a small delay (in minutes), you will receive a message in your Secure Message Center asking to confirm that you made this request. Confirm the request. This response and verification happens with each new Client UID you submit.
Make the OFX request again, and you should receive your transactions!
Comments
Many thanks to Harry Sit # thefinancebuff.com for doing most of the work!!
More is possible through OFX, it's a complicated standard. Look to the specification for details.
You can also use GnuCash to see other promising settings.
This is using OFX 1.02, but Chase is now at 2.2
References
https://thefinancebuff.com/replacing-microsoft-money-part-5-ofx-scripts.html#comments
http://www.ofx.net/
http://www.ofxhome.com/
http://www.ofxhome.com/ofxforum/viewtopic.php?id=47456
https://rhye.org/post/parsing-ofx-leex/
since October 5, 2022, Chase disconnected ofx.chase.com and look like you have to go aggregators like Quicken/MD+ to get your data.
As HLE indicates, Chase has killed OFX/DirectConnect as of late Sept./early Oct. 2022. Here are some related articles:
"As of October 6th, 2022, Chase will no longer be supporting Direct Connect/OFX which includes 3rd-party bill pay. Along with some of the other larger financial institutions, Chase has moved to the Open Banking connection method for transaction importing. A link to an article that explains what Open Banking is all about is listed below."
https://www.banktivity.com/support/articles/banktivity-7/ofx-direct-connect-will-no-longer-be-supported-by-chase-as-of-october-6th-2022/
"Chase Bank is changing the way it connects with personal finance management solutions like Quicken. To keep Quicken connected to your Chase account you'll need to switch you connection method on or before September 26, 2022."
https://community.quicken.com/discussion/7916266/quicken-chase-announce-killing-link-to-chase-direct-connect-bill-pay
Possible solutions for Moneydance users:
http://infinitekind.tenderapp.com/discussions/online-banking/23881-chase-bank-accounts-no-longer-can-connect
It sounds like .QXF files contain the same/similar data as .OFX files and the downloading of such files may be scriptable. I will update this answer if I find out more.
Related
Dear Yodlee / #apoorv / #Shreyans,
A client tried adding a Bank of America account. Bank of America is site ID 409, but when adding an account via the Site-based APIs, we get back this response:
{
"errorOccurred": "true",
"exceptionType": "com.yodlee.core.IllegalArgumentValueException",
"referenceCode": "_55558c4f-9107-4ae2-b2ef-1118b5701fca",
"message": "Invalid argument value: Site is not having any content service that is enabled and is not custom409 for: siteId"
}
I used the SiteTraversal/getAllSites API to check the list and it appears that Site 409 has been removed and there is now Site 2852 "Bank of America (US)" instead.
I have a few questions.
a) can you confirm that 409 has been removed?
b) if you just remove banks from your system and give them different ID numbers what happens to all the accounts added to that bank? what would have happened to my users with accounts under Site 409 "Bank of America (US)"? They would just stop working?
c) like all Yodlee-based apps, we need to cache the bank list within our own database to give the users a good experience. If we have to use the APIs constantly to get basic bank data, our apps would be unusably slow. So we cache them, obviously.
However, if you are deleting banks from your list regularly, how are we supposed to handle this on our side?
The SiteTraversal/getAllSites API data response is MASSIVE - really massive. This usually isn't an issue. We just run through it and create/update our internal cached bank records.
But if we have to catch deletions, that changes everything. We would have to hold the entire response JSON data in memory, even though it is enormous, extract all the site ID numbers, then grab all of our cached site ID numbers, and run them against each other to see which ID numbers are not in both lists, which means those are now removed,. The server memory required for such a large operation is substantial, and I don't want to have to do that if there is another way.
What is your guidance on this?
a) can you confirm that 409 has been removed?
Yes it has been disabled.
b) if you just remove banks from your system and give them different ID numbers what happens to all the accounts added to that bank? what would have happened to my users with accounts under Site 409 "Bank of America (US)"? They would just stop working?
If we remove and create new site for the same FI, then ideally we migrate the users from old site to the new site.
Or
We leave the users on the old site with cache refresh turned on and hence those accounts refreshes on a daily basis but no new accounts can be added to the disabled site.
c) like all Yodlee-based apps, we need to cache the bank list within our own database to give the users a good experience. If we have to use the APIs constantly to get basic bank data, our apps would be unusably slow. So we cache them, obviously.
However, if you are deleting banks from your list regularly, how are we supposed to handle this on our side?
We usually recommend calling the SiteTraversal/getAllSites once in a day and update the cached data at your end.
Thanks for you feedback at the end, we will definetely take this into consideration and see what we can do to help on this.
I am using an OFX download function written in Python similar to ofxclient to download bank and credit card transactions. However, it only retreives posted transactions, not ones that are in progress. This results in the account infomation frequently being out of date by a day or more. I realize these pending transactions could be temporary (holds, etc.) But most of the time they turn into permanent transactions after they post or drop. But is there some different OFX command I can use to request pending transactions, with the understanding that they are subject to change? It is possible to see them from the web site of every financial institution I have tried, but trying to scrape web sites is out of the question and OFX I though was designed to avoid the need for such non-standard procecures.
Try the <INCLUDEPENDING> flag; see OFX Spec 2.2 - 2017, page 207.
It defaults to N. So, try:
<INCLUDEPENDING>Y
Note: The backend server must support this feature, which is available with OFX 2.2 (VERSION:220).
I am new to Clickbank.
I want to try out the API for the same.
But I am stuck in between.
Can anyone guide me through the steps to successfully create a product.
I am getting some errors
You must make a test purchase before submiting this request.
A footer disclaimer is required for all Pitch and Thank You pages.
Also wanted to know, like how can I setup the sandbox account?
Please help me out.
Thanks in advance.
This question was asked a very long time ago but I just happened across it and know the answers.
First, however I think anyone starting on ClickBank, technical or otherwise, will benefit from the following: https://www.clickbank.com/launch-checklist/
Now, to answer the question(s):
Test Purchase:
• Can't do this without creating a product first
• To create a product you do the following:
Login to the account
Click: Vendor Settings -> My Products
On this page locate the list of ADD NEW buttons & Click Product
The product editor pretty well walks you through the process
AND now for the test purchase.
That process is described here: https://support.clickbank.com/hc/en-us/articles/360036958431-How-do-I-test-a-payment-link-
Footer/disclaimer:
This is what is known as the ClickBank Trust Badge currently, (not sure about 9years ago).
It's a little element that you copy and paste into your webpage, after configuring what you want it to look like & where you want it to be, from the available options.
To find and set it up:
Login to the account
Click Vendor Settings -> My Site
Scroll down to the section with the title "ClickBank Trust Badge - Injection Code"
If you like the default setup you can copy what's in the Javascript Snippet field
If you want to change where it's located and colors click the Configure Settings button (not going to describe everything here as it's pretty straight forward as well)
ClickBank APIs
Last, you mentioned wanting to use the ClickBank API, which I happen to know very well. However, the documentation for it is also actually pretty good so let me start off with that:
General ClickBank API documentation
Additionally each APIs primary endpoint is self documenting. Additionally this documentation tends to be the most relevant for a programmer
Example of self documenting endpoint: https://api.clickbank.com/rest/1.3/orders2
So, it's worth noting the following that are required to use the API:
You must have an HTTP header of "Authorization" and it must be set to both of the API keys for an account.
Both keys refers to the API- "Clerk Key" as well as the DEV- "Developer Key"
Enter them both, separated by a colon ":" as the value of the Authorization key with the DEV- key first (DEV-A23478C...:API-IA23456...)
You must also use the correct HTTP request type for the query you are wanting to make (the only two that are utilized are GET and POST)
Examples:(NOTE: ACCOUNT_NAME_HERE is the ClickBank "nickname" or account name)
Single transaction: https://api.clickbank.com/rest/1.3/orders2/RECEIPT_NUMBER_HERE
List transactions by date range and specific account: https://api.clickbank.com/rest/1.3/orders2/list?vendor=ACCOUNTNAME_HERE&startDate=2021-12-11&endDate=2021-12-14
Count of transactions by date range: https://api.clickbank.com/rest/1.3/orders2/count/?vendor=ACCOUNT_NAME_HERE&startDate=2022-01-01&endDate=2022-01-01
Monetary value of transactions by date range: https://api.clickbank.com/rest/1.3/quickstats/count/?account=ACCOUNT_NAME_HERE&startDate=2022-02-01&endDate=2022-02-10
Sending shipping data for physical products (POST): https://api.clickbank.com/rest/1.3/shipping2/shipnotice/4NVXUFNW?item=2&date=2018-08-14&carrier=UPS&tracking=1NH323452345WODFS&comments=Test%20again%20comment%20with%20spaces10%20receipt=4NVXUFNW
I am looking for a way or a plugin so that trac sends me email about the number of new or closed tickets (and some information about these tickets also ) for a specific duration lets say for the last three days.
Basically I need to know how many tickets have been created in last week and how many of them have been closed at the end of week.
Of course the email only should be sent to the admin and not to all the users.
For additional Trac funcionality we have Trac plugins, yes. And the first place to look for them is trac-hacks.org .
The excellent TagsPlugin in use overthere already delivers some hints on resources tagged with notification or notifications. The most comprehensive and mature solution is certainly TracAnnouncer with a just reworked configuration interface providing a highly sophisticated opt-in and opt-out subscription system. Unfortunately digest notification are not integrated today.
Still there are other plugins, that fill in the gap, i.e. check the XMailPlugin. It claims to do configurable instant, daily and weekly notifications, so this may be for you. Since this is a relativly new plugin, you should expect some pending issues, but the author might be very open to your suggestion. If you're becoming a heavy user giving valuable test feedback and a bit lucky too, asking kindly could be enought to make things happen.
There's a slightly different way to solve this problem that doesn't require any plugins. First, create a custom "timeline" view that displays the information that you want. In your example, this would be all "opened and closed tickets" starting from "today" and going back three days. When viewing this custom view, you should see a link at the bottom of the page that says "RSS Feed" (on my system, the resulting URL looks something like this: http://myserver/timeline?ticket=on&max=50&authors=&daysback=3&format=rss). Click on this link to subscribe to the feed using your web browser, email client, or other program capable of reading feeds. Now, you can view the results live at any time. What you can do at this point is only limited by the capabilities of your feed reader app, but most can at least be configured to notify you when the feed is updated.
Out of interest and because it infuriates me, I was wondering if SOmebody here might happen to work for a bank or otherwise know the answer to this.
I've used a few online banking sites (UK and N.America) and they universally enforce a password pattern of /[\w\d]{6,8}/ Sometimes, maybe you get to use underscore, but never ever do you get to have /.{6,20}/ that you get (more or less) with just about every !banking site you'll encounter.
I have been told that this is to do with storage space, but the maths don't seem to support that. Assuming that banks keep shadow tables for your password record, let's generously say an average of 10 per account, then doubling the allowed length of the password and doubling the bit width of the character set based on an 8char 8bit existing format means an extra 11*2*8 = 176 bytes per account, so ~168Mb per 1M accounts. Let's say it's a gigantic bank supporting 100M accounts - that's still only 16Gb!
It can't be that simple can it? Surely my numbers are off base.
Or is the answer here that banks being banks they have no better reason for this than they're plodding dinosaurs.
Does anyone know a technical reason why my password for www.random.com/forum is stronger than the one for my bank?
If the stories I've heard about certain banks are true...
It's because whenever you enter your password:
The web server sends it over a half-kilometre-long serial cable to an old 386 in an abandoned office, running the UI (Compiled using a custom-hacked version of Borland C 1.0) that was used by bank managers in 1989, which doesn't have a serial interface so it has to go through another device that simulates keypresses on an AT keyboard.
This program inserts your request including your password (encrypted using a custom algorithm that's too weak to be used anymore but which cannot be disabled in the software) into a FoxPro database on a NetWare file server in a different abandoned office at the opposite end of the building (just because it would fall to bits if they tried to move it.)
Back in the 1st abandoned office another old 386, constantly polling the FoxPro database for new records, detects this request and forwards it over an even slower serial cable (this time in EBCDIC) to another box in a 3rd office that is emulating a PDP11 running the actual COBOL program that maintains the accounts.
Unfortunately they also still need the real PDP11, because it had custom microcode for another secure encryption algorithm (which they can't extract or the anti-tamper device will erase it.) The PDP11 can't handle the increased workload of all accounts opened since 1981 (the year of their first unsuccessful attempt to retire it) so now (via another layer of screen scrapers and emulated hard disks) it is tricked into performing a subset of functions (including password verification) on behalf of the main server.
So your password can only use the common subset of the character sets supported by all these systems, and can only be as long as the shortest database field involved.
I actually work in a bank right now, and have worked in quite a few in the past.
The primary reason that this happens is that in general the people who are ultimately responsible for making these decisions are not the people who end up implementing them.
The "Business Unit" of a bank are the non-technical business experts who end up making these decisions.
In many cases, technical objections will be overruled for political or business reasons. But this isn't exclusive to banking. It happens in any industry where technical considerations are often not the primary concern.
Banks use online services primarily as an interface to legacy systems. Your password is probably being processed by an IBM mainframe somewhere, written in Cobol, and the password structure may have been designed in the 70's.
In addition, because banks are such political structures, the management primarily sees "concrete" results so issues such as security are not addressed until it becomes a hot issue and then there is an "initiative" to address it.
At one bank I worked for, the production password was the same as the userid (same idea as logging in with "root" "root"). The user passwords could be reset online to a combination of first N letters of your last name + last 4 digits of your SSN, so any user could reset your password if they knew your name and SSN and loginas you .
Probably most of banking systems were developed long time ago, when 8 character passwords were considered secured. I don't think anyone would consider brute forcing passwords from banking accounts anyway, 8 characters it still a lot. I bet all banks block an account after 3 attempts or so.
Here is a "bug" I got logged in Bugzilla regarding a site I'd built for a client recently (not a bank, thankfully!):
"It seems that the user is forced to use a ! or _ in their password* which seems a bit odd to me. Can this ben updated so that it is a 6 - 8 digit password that can only use alphanumerics?"
Actually, it was at least one non alpha-numeric character