Already right now in Germany there are a lot of banks that share a common API format which is why there are a lot of banking apps where you can just log into your bank and don't need bank specific apps. It's called HBCI / FinTS (https://en.wikipedia.org/wiki/FinTS) and it's great to have that possibility without doing some web-scraping to get your data out.
PSD2 and “open” banking is bullshit. I wish this myth would die - it is anything but “open”.
If you want to gain access to APIs, you need to become an “AISP” (as they are called in the UK), this requires a certification and a load of other nonsense akin to PCI-DSS. This is for read-only access - for “write” access including the ability to edit payees or make payments you need to become a “PISP” which I assume requires even more paperwork.
I also said APIs because the regulation does not mandate any kind of API format, so every bank has their own with different capabilities as far as what data is returned and in which format. Some of them are truly awful.
And finally, “open” banking still does not allow you to get a personal access token for your own account.
> If you want to gain access to APIs, you need to become an “AISP”
It's more complicated than that.
Banks can give unregulated entities access to their APIs, but they don't because IMO providing API access is directly opposed to their interests. If you want to be statutorily entitled to API access you need to be a registered AISP or PISP.
Unfortunately what an AIS is is very specific, i.e. showing the account owner aggregated information, before or after processing, about one or more payment accounts. If your product doesn't do this, e.g. credit scoring using the user's bank transactions instead of credit bureaux, then you're not performing a regulated activity, therefore the regulator has nothing to authorise, and you can't enjoy the resulting entitlement of API access.
This means there are whole classes of (unregulated) applications that won't be allowed to exist by banks if they adopt the position of granting access only to regulated entities.
> this requires a certification and a load of other nonsense akin to PCI-DSS
AIS and PIS have become regulated activities as a result of PSD2. This is not the same as PCI-DSS. Becoming a (P|A)ISP means becoming supervised by the local regulator as an authorised financial institution. This involves a lot of paperwork, a £1,500 application fee, insurance, fees for any professional services you needed to complete the application (lawyer), and 3 months (longer if your application is incomplete or has other issues).
> for “write” access including the ability to edit payees or make payments you need to become a “PISP” which I assume requires even more paperwork.
And €50,000 own capital requirements.
> I also said APIs because the regulation does not mandate any kind of API format, so every bank has their own with different capabilities as far as what data is returned and in which format. Some of them are truly awful.
This is true at the moment for Europe but notionally incorrect for the 9 largest banks in the UK, which are subject to parallel domestic measures ordered by the Competition and Markets Authority. There is a spec, but there are many problems with the governance, implementation, etc.
To be honest those requirements sound perfect for a scrappy startup. Just enough of a moat to deter 99% of drive by hackers, but within the reach of any reasonably serious startup.
- £1,500 application fee
- €50,000 own capital requirements
If you're aiming to play in this league you really should be able to scrape together this kind of money.
- 3 months wait
Can also be seen as a 3 month delay imposed on your competitors.
Of course if you're aiming to use the API for your own personal needs only- then yeah, these requirements suck.
I'm actually investigating the ins and outs of building a product that interposes between e-money gateways and businesses implementing them. It has three purposes:
- Data synchronization. Usually, either because you're sane, or have legal obligations to do so, you maintain your own ledgers in addition to those provided by the payment service provider. It's hard to do, leads to countless hours of manual maintenance when something goes wrong which of course alienates a (hopefully small) part of your clients.
- Proper handling of a "distributed system". By distributed system I mean a CRUD remote service with asynchronous notifications, not paxos-based phd-level systems. I'm not trying to downplay the difficulty of communicating with "simple" systems like this, quite the contrary. There can fail in quite surprising ways. I'm not even mentioning the fact payment-services have unrollbackable real-world consequences, like money-real. It's really easy to lose money when misusing a payment system.
- Providing a meta-interface to many payment-systems.
-- Migrating from one payment service to another one can turn out to be a multiple-people year-long project for some?/many? businesses. This is even more impactful for startups that manage to break through and need to find a better deal with a different payment service as their user base sky-rockets.
-- In some countries (for instance Morocco), there is no deal between international players in the PSP market (PayPal, Stripe, etc ...) and national banks. To perform electronic payments, you must communicate with the system of a state-controlled entity. Businesses that want to extend their market to these countries must support additional developments, that may well cost them as much as plugging to yet another payment system.
I tried my best reading the PSD2, but I wasn't able to determine if the law applied recursively: for instance, as an AISP (Account Information Service Provider), can I legally aggregate data coming from other AISPs (i.e. with the access to that data being granted to me by the law) ?
Anyway, for technical, UX, and legal reasons (mainly avoiding the 50k€ requirement) I thought it would be better to abandon the idea of proposing my clients access to a remote service but to instead loan them a local service as a brick to place in their own infrastructure (in the form of a container for instance). This service's data would be theirs and stored in their own database. To use it they would configure it with their own API keys to these various payment systems.
What would be the legal requirements under such a configuration ?
The problem is that your appliance/container will not be allowed to access the AISP-only APIs provided by the banks, unless your client themselves become an AISP.
Not an issue if you're doing screen-scraping though, I agree (although in that case, do you even care about AISP certifications? You can so scraping-as-a-service and in fact there is an entire industry around this already).
> The problem is that your appliance/container will not be allowed to access the AISP-only APIs provided by the banks, unless your client themselves become an AISP.
Makes sense, at least on a technical level. Ditto if I try to place myself as proxy between a business and is PSP.
But let me express doubts by referring to the PSD2[1] itself. TL;DR -> I'm not sure offering my product as a container disqualifies it from being a service from a legal standpoint.
> Negative scope
This Directive shall apply to none of the following:
...
services provided by technical service providers, which
support the provision of payment services, without them
entering at any time into possession of the funds to be
transferred, including processing and storage of data, trust
and privacy protection services, data and entity authentication,
information technology (IT) and communication
network provision, provision and maintenance of terminals
and devices used for payment services;
Yet the definition of a payment service (last page of the document[1]), seems to indeed indicate such a container would be a payment service.
> ANNEX
PAYMENT SERVICES (DEFINITION 3 IN ARTICLE 4)
...
Execution of payment transactions where the consent of the payer to execute a payment transaction is given by means
of any telecommunication, digital or IT device and the payment is made to the telecommunication, IT system or
network operator, acting only as an intermediary between the payment service user and the supplier of the goods and
services.
Here is how I understand this:
- if I'm offering a database hosting service that happens to be used in a payment system, I'm not tied to the PSD2 (too low level).
- however if I manage this data at the semantic level of a payment system, I'm a payment service not matter how far I try to get from what a "service" technically is.
Now, here is what doesn't hold with this feeble interpretation:
Under these terms, an open-source client to a european PSP (there are many on GitHub) should be regulated by the PSD2...
From what I've heard the main problem is banks are afraid popular API access would overload their mainframe-era systems that don't scale and can't scale.
All the banks I'm with use rest APIs in their apps (you can see this by MITMing the traffic), no "private protocol" whatever the hell that is.
As for controlling load, I'm not sure I follow. If you have 1m people with the mobile app installed and all of them decide to check their balance at the same time your systems are going to crumble if you've only provisioned for 10,000.
Web/Mobile banking doesn't talk to the mainframes directly, it's essentially a caching layer which gets committed later when the mainframe does it's job. Not much different from your average web app just with longer delays.
I think you aren't using the term API correctly. This discussion is about APIs for third party developers to write apps. The fact that banks own mobile apps often use REST to communicate with their backend does not make such a protocol an API. For one it's not documented, for another it may change without notice.
Of course if you define "API" to mean literally any form of communication between processes or devices then sure. But then you'd have to consider GSM or FTP or TCP/IP itself to be APIs and I never saw them described that way.
My main point is that an interface that's just being driven by human interaction has very predictable load characteristics. If you open up a true API to third party developers they may come up with new uses that aren't directly human driven or may even be batch jobs. You don't have much control over your inbound workloads anymore.
FTP TCP and IP are protocols, GSM is a european standard and REST is an easy method for building applications in which the backend is called the API (application programming interface) which typically use the http protocol. RESTful generally means using CRUD create, read, update and delete although it isn't a standard.
Some api's are private as in the one your bank's mobile app most likely uses. Some companies offer their API's to the public. They are both still APIs though.
> I think you aren't using the term API correctly.
I am. Public or private an API is an API. You seem to be under the impression that only a public API can be called an API which is nonsense.
> This discussion is about APIs for third party developers to write apps.
Which doesn't change the fact they have private APIs. My point was that they already have these APIs but they aren't public. They could be opened with minimal effort (compared to writing entirely new ones for PDS2).
> The fact that banks own mobile apps often use REST to communicate with their backend does not make such a protocol an API.
Of course it does, you know by definition[1].
> For one it's not documented, for another it may change without notice.
They are documented, but just like the APIs the documentation isn't public.
> Of course if you define "API" to mean literally any form of communication between processes or devices then sure. But then you'd have to consider GSM or FTP or TCP/IP itself to be APIs and I never saw them described that way.
No because I'm not an idiot. Those are protocols not APIs.
> My main point is that an interface that's just being driven by human interaction has very predictable load characteristics. If you open up a true API to third party developers they may come up with new uses that aren't directly human driven or may even be batch jobs. You don't have much control over your inbound workloads anymore.
Your case falls apart when you consider that there are already screen scraping services used by companies like Mint, Emma etc... these use way more resources than hitting an API and are already in use by hundreds of thousands of people.
They can just provide them as-is, with no guarantees, and a big "things can and will break" disclaimer. This will be unusable for commercial usage, but will allow power users to automate their finances.
I've only just joined so this isn't exactly a recommendation, but Monzo looks super exciting because of two features: instantly reporting transactions, and an API that lets you access your own transactions. If you've only ever used a shit bank, look how amazing this looks: https://docs.monzo.com/#list-transactions (caveat: I haven't tried it yet!)
Not true. The spec is loose, many fields are not mandatory, and the "conformance suite" only tests the security profile, not anything related to the schema. Even with that minimal level of scrutiny as of last month none of the CMA9 were compliant with the CS.
My problem is that it does not even allow access to your own account. Nobody has a problem with access to others' accounts being regulated. I just want to do whatever I want with my own account.
If you are allowed to access your data, then you can grant that access to third parties (pass along the API token). I happen to think that is great, but we live in a time where the idea of my sharing my Facebook account with an app is considered a problem, because it has a list of my friends.
My financial history contains a lot of metadata about third parties.
This is exactly the intersection between this overlay strict interpretation of privacy and my right to share my side of the data with third parties.
At the moment you can already grant third parties access to your data - you can pass along your online banking credentials and they will scrape the web UI (there is an entire industry built on that - companies like TrueLayer will take any bank’s credentials and some cash and give you JSON in exchange, scraping the online banking UI behind the scenes).
Stupid people will be stupid and will find a way to shoot themselves in the foot; doesn’t mean I should be prevented from accessing my own data.
You are not and were never prevented from accessing your own data. You keep repeating that while also mentioning you have options to access it.
You may not like the options you have to access that data because you have different needs than most other people. But insisting you're not allowed feels more than just exaggeration.
Open banking means it's not 100% proprietary and exclusive to each bank, it doesn't mean they have to open all doors and say "do what you want, I'm not even here". Regulation is there with a reason especially when dealing with such sensitive topics. You get access but you have to meet some conditions and the bar will be set according to the sensitivity: confidential personal data and actual money? It's going to be pretty high.
People are more than happy to blame regulators when they fail to put measures in place to protect people from major issues but will complain nonetheless if the regulation is there.
I am prevented from accessing my own data. A lot of bank's online banking is absolutely awful and doesn't go back more than 3 months worth of transactions.
Thankfully none of this bullshit actually applies to me (I use Monzo Bank which does have an API) but I feel the pain for everyone else.
> it doesn't mean they have to open all doors and say "do what you want, I'm not even here"
So hold on, does this means we now need regulation on how we can use cash? Because at the moment, stupid people can withdraw all their cash and throw it away, and nobody is there to prevent them from doing so.
How about we let people be responsible for their own data, and let them do whatever they want with it?
> online banking is absolutely awful and doesn't go back more than 3 months
It doesn't mean you can't request it directly with the bank. It is more cumbersome but they have to be able to provide that data as far back as the country's laws require them to keep it.
It's just that usually data older than 12-24 months is archived and I can guarantee you no API no matter how open it is will allow you to get the data directly from the archive. That's not what the system is meant to do. You'll still get 1-3 years but using a generic app instead of a proprietary one.
And you just moved the goalposts.
> So hold on, does this means we now need regulation on how we can use cash?
Moving your own cash has always been your business. But touch someone else's cash or account has always been regulated, yes. Some companies manage to exploit some gaps in that regulation and give you something but that's not because they should, it's because they can :).
Let me give you an example: you can treat your illness as you please. But if you want to treat other people's illnesses you need a medical degree. A pretty high bar. Unfair, right? :)
> How about we let people be responsible for their own data, and let them do whatever they want with it?
You're basically advocating for the removal of most regulation anywhere. I'm not sure you understand the implications. Which makes me think you'd be the first one to complain that nobody put rules in pace so you don't get bitten just as soon as "being responsible" bites you back.
My Monzo API allows me to go back to when I opened the account (back then it was just a prepaid card) in 2016. Somehow they are able to get the data directly from this "archive" which frankly shouldn't exist - Facebook is able to lookup stuff from 10 years ago instantly - don't tell me a bank can't do the same.
> But touch someone else's cash or account has always been regulated, yes
My argument here is about my own account. I'm even happy to send a letter stating that I am not an idiot and assume all responsibility just to get a personal access token.
> You're basically advocating for the removal of most regulation anywhere
I'm not advocating for no regulations everywhere - some stuff absolutely does need to be regulated, like massive tracking across the web. However when the user is in control and is knowingly handing over the key to their account, I'm happy for there to be no regulations. Same way nobody is preventing you from handing over your house keys to someone.
I don’t see account access being abused either. People could already be giving out their credentials, but somehow it’s not happening, so I don’t see the argument against personal access tokens.
They are not using APIs to begin with. I'm not sure what else is there to lock down.
Maybe we should just let idiots be idiots, and natural selection (or in this case, financial selection?) do its thing and the problem will go away eventually?
> They are not using APIs to begin with. I'm not sure what else is there to lock down.
It's a bit like getting your app from the app store, or system repository, rather than downloading a random exe from the internet. Apple's walled garden comes in for a lot of criticism, but it does stop a lot of crap getting through. Getting your PSD2 enabled, regulated app from a curated list rather than any random piece of crapware is the same sort of idea.
> Maybe we should just let idiots be idiots...
Eh, if that was going to work it would have done by now. They'll only become a burden on the state.
> My problem is that it does not even allow access to your own account.
Here, use our application to aggregate data about your financial history, just give it access to your data and it'll give you all sorts of useful stats.
Do not look behind the curtain, we're definitely not snaffling your data and giving it to anyone we feel like...
--edit--
The number of people who would be competent to write their own API-using software is pretty tiny as a proportion of the population. If you allow people access to their own account data via an API then they will seek out software to help them access it. The regulations are about who can produce and distribute such software.
> If you allow people access to their own account data via an API then they will seek out software to help them access it
Is that a bad thing? How about we let people do whatever they want with their data?
Not to mention the lack of APIs doesn’t stop this - there is an entire industry built on top of scraping bank’s web UIs. Companies like TrueLayer will happily take online banking credentials and provide you with an API, scraping the bank’s UI behind the scenes. A lot of financial aggregator apps use it for ages now.
Of course not. But it makes sense to ensure that the vendors of these products are FCA approved.
> How about we let people do whatever they want with their data?
For the same reason we can't have quite a lot of other nice things - scammers and shysters will take advantage.
> there is an entire industry built on top of scraping bank’s web UIs.
There is, and now you can have a choice - a well functioning, secure ecosystem with oversight, or giving your login credentials to some third party to abuse as they see fit.
Allowing anyone to use any software to access their banking data would allow them unprecedented abilities to automate, and attack.
I'm sorry if you don't feel that's adequate. Perhaps you should have a conversation with one of the many people that object to OpenBanking because it's far too permissive and they don't want the possibility of any third party getting their banking data, ever, oversight or not.
> Allowing anyone to use any software to access their banking data would allow them unprecedented abilities to automate, and attack.
In certain countries (Germany, etc) there are actually open protocols (FinTS/HBCI, etc) that banks conform to and allow any software to gain access to the accounts provided the proper credentials are supplied, and it doesn't look like the world has melted down.
AFAICT FinTS wasn't ever massively widely supported and has never been fully implemented, there seems to be little information about it at all.
What info I can find appears in discussions related to PSD2, and one presumes there are reasons the EU didn't pick up that model but issued what it did.
One of the projects using these protocols seems to be openbankproject.com, but they have their apps go through approvals as well, using OAuth flows in a similar way to OpenBanking in the UK.
Eh. I don't really see how, even from your perspective, you can be against PSD and Open Banking - it forces all banks in the EU to open up more than the vast majority do now.
To be fair, I am not against open banking - it’s definitely a step in the right direction. But I just want people to know that it’s not a silver bullet and it’s got many shortcomings. It’s definitely not the solution to the lack of bank’s APIs, and more needs to be done.
Do you think it's appropriate an app doing something as trivial as calculating much you spend on Starbucks each month is now a regulated activity? I don't.
It sound more like Cambridge Analytica will be able to get access to people's banking data by making themselves an AISP, while I still have to scrap my fucking bank site to automate my own finanses. This is totally backwards, but that's profit motive for you.
Cambridge Analytica didn't make or market such an app to them. It was some academic who made the app and then turned around and sold the data. This academic has now been largely erased from the story, presumably because journalists tend to like academics and anyway "one guy screwed up" is not a story whereas "clash of the corporate titans" is.
So you take issue with the fact that there's a high bar when dealing with personal data and real money? Especially when this gives you access to do it en-masse?
It's open, just not the "open" you imagine. Like anyone from the street being allowed to do it.
The problem is that the value of an API is in the fact that it is open as in open, not "open" like "open banking".
An API that can only be accessed by a few huge players is next to useless. Those guys have already figured out a workaround for the lack of APIs, mainly screen-scraping.
However the real innovation comes from small startups, sometimes originating from a one-man side-project - this "open" banking completely forgets that.
And finally, my problem is that it does not even allow access to your own account. Let's forget about accessing other accounts for a second - I just want to do whatever I want with my own account.
Maybe the problem arises from this different interpretation for "open" that different people have. Look, the Linux source code is open. But doing something meaningful with it takes a huge effort. A one man team can't build Android out of Linux. This doesn't make it less open.
The bar is higher because those companies will literally have access to to all of you financial information and your money. And not just yours, but of all the customers of all the banks. There simply must be some framework in place that sets clear regulation as to what and how things will be done. Otherwise you're flirting with disaster. Lack of proper bank supervision is what triggered the last financial crisis. You think a 3rd party will fare better if left to their devices? All the responsibility the bank has towards you, the client, should be mirrored to the 3rd party. You have high expectations of the bank, why would you accept less from the middle man?
As for the "do what I want with my own account", you can to a degree. All banks provide you with internet banking, an app, a website, a person behind a desk. You have access to all of your data, just not how you want it. And the how is sensitive enough to require regulation.
P.S. The requirements are in no way unachievable for a small startup. It takes a bit of effort, I agree. But if those requirements are what stop you then you're in the wrong business. The bar in fintech is set a bit higher than other industries as it should be.
It's mostly because your Facebook account doesn't have a balance :).
On the other hand I'm not sure what data you need exported and can't. A bank data export is the monthly bank statement. Most banks allow you to to export every transaction going back some years from the app or website. Going further back you can address the bank and they will provide you with such an export going as far back as the local laws mandate.
You're going to have some issues getting realtime access and this is the how I was referring to. Pretty sure Facebook doesn't help you with this either.
Honestly? My Facebook data (back when I had one) contains way more valuable data than my bank statement.
Well let me give you a real example - my personal bank account is Monzo so there is an API and webhooks and all is well.
My business account doesn't yet have an API (it's Starling Bank - a modern bank so they're planning to have one that gives out personal access tokens without needing to be an AISP). I have accounting software (FreeAgent) that has an API. I want to make it so that every time I use the business bank card it creates a new expense (and if it's things I expect - food deliveries, etc - automatically look up the receipt in my inbox and attach it to the expense entry in the accounting software). Same thing for incoming payments - if I receive an incoming payment with a non-blank reference, look through the invoices to see if any of the references match, if so, mark it as paid and send a thank you email to the client.
Honestly. [1]
Make it $500. $1000. Unless you put the next winning lottery numbers in there, your data isn't that valuable. And in case you are wondering some data is heavily regulated anyway.
But you keep moving the goalposts, you complain about something, it turns into a non-issue, then move to something else. First it was that you don't have access to your data, then it turned into web banking only providing 3 years of the data you don't have access to (?), then it was back to no access to data.
For my last reply I'll rehash it:
a) you do have access to all your data just not how you want it: you want access via a generic interface of your choosing so that you may process it somehow. They provide access via their proprietary interface making the processing more cumbersome.
b) smaller banks will offer APIs for individual use because it's cheaper for them and want to attract customers, larger banks don't because it's expensive, riskier, and they already have the customers.
c') your bank offers you the API because you are its customer and they have control. They do not offer that access to a random 3rd party in bulk because that third party is not their customer and they lose control (in the bad way).
d) no bank really wants to offer bulk access to APIs when the regulation sets a low bar because it's very risky and they are taking most of the risk.
Hence the regulation: you get access to the APIs if you meet some criteria.
Real world example? I want to be Bank of close04 but although I have a hand calculator and a pretty good hiding spot for money they still set the bar slightly too high. [2] Now sit on it, think it through and let me know why a bank holding your money would be treated any differently from a 3rd party that can perform close to any operation with that money. And why your earlier statement that "people should be free to [...]" doesn't make sense in the context of current day reality.
People's misery tends to turn into misery for the state. Which is why the state is regulating stuff. The more sensitive the topic, the higher the bar. Money is sensitive.
P.S. The argument that the bar for open banking is set high is to discourage competition and keep power in the hands of the banks is total BS, visible from afar. There will be dozens and dozens of 3rd parties more than able to fill the role. It could be "Amazon Financial Services", it could be one of the banks, it could be a 2 man startup with moderate financing. Literally thousands of startups manage to raise over $10 million.
> Unless you put the next winning lottery numbers in there, your data isn't that valuable.
My Facebook or other data obtained through web tracking is definitely more valuable than my boring bank balance.
The thing about web banking not providing 3 years was just to refute your argument about how banks apparently provide me all the data I need, which clearly isn't the case.
> you do have access to all your data just not how you want it
I do not. In my previous response I told you that most banks do not provide more than 3 months of data.
> your bank offers you the API because you are its customer and they have control
All I'm asking for is that banks provide personal access tokens to any of their customers. I don't mind the regulations being there for massive-scale access, but I do want any customer who wants to automate their finances to be able to do so.
> My Facebook or other data obtained through web tracking is definitely more valuable than my boring bank balance.
That data is valuable to Facebook. Your bank balance is valuable to you. That's why you don't send all your money to Facebook, just your data.
> I do not [...]
You do. You wanted a bank data export: it's the 3 years from the website or go to the bank and ask the guy at the counter for more if it still exists.
Data retention periods are mandated by law. Some data is kept 2 years, most data for 5-7, and some for even more. There's also a mandated period in which the data must be readily accessible. After that it's archived and put in cold storage, or deleted. This is why the website doesn't give it to you and why an API won't magically provide it. That website is also using an API to give you the data. Just not an API you can access.
Don't worry, you will get API access to your account when the bank is ready with it. It's not something you want to rush, especially when you have millions of customers. But if you think just anyone can get bulk access to the API and provide financial services you've got another thing coming.
You have poor knowledge of this topic. And that's OK, that's how most people are. But that's exactly why regulation is put in place. So others don't take advantage of this - your bank or a 3rd party.
I absolutely do not want any old hacker to be building software that can talk to bank accounts. I want a minimal level of regulation and insurance, to make sure that they aren't doing terrible things with it, and that they are easy to track down and deal with when they mess it up.
Is this new initiative strictly for an API between the official banks or there's a chance that a regular company or, let's say a private person, can use it to access its own data & submit transfers?
In a related note, I do hope that the German "lastschriftmandat"/direct debit gets also replaced with something more transparent and with a better control. Similar to an e-invoice concept used by a few other countries like Estonia.
It's not completely public, but it's open to all companies and people. Your application needs to meet certain requirements and needs to be approved etc.
In the UK the fintech (Financial Tech) scene is becoming more prevalent, for the better.
Recently I switched to a new online-only bank called Monzo. It's fully licensed and all accounts are insured up to a certain amount by the UK government. It's great. They're in the top charts for apps in the UK now on the iOS App Store. There's a few other alternatives like Starling Bank and Revolut too.
They're very good. They're open about their tech stack with developer blogs and it's a modern stack which lets them iterate in a quick and agile manner unlike the legacy banks.
You get push notifications on every payment (usually you get the notification before the payment has even processed on the vendor's end!). Tells you exactly how much you've been spending every day.
They've got RESTful JSON APIs you can integrate with if you want to and they also have the option in the app to easily export your data into CSV or Quickbooks format. They even have IFTTT integration.
Revolut are a nightmare. After using it for several months and fully verified I apparently entered a CVV incorrectly on one transaction. Revolut blocked the card but with no notification, and no inapp indicators, all showed normal in app, all toggled enabled for maximum flexibility. It took ages to figure out, but swiping the card or using online was now returning to the merchant 'FRAUD/STOLEN' marker rather than just insufficient funds, this lead to Ayden blocking me from merchants and other hell. Best of all support kept telling me my account was fine and all enabled, it was only after Twitter escalation I learnt about a backend block their support staff couldn't see. Ridiculous, weeks to sort, dozens of tickets, suggestion to train support staff or provide in app indicator of block was ignored.This shit still happens today, avoid Revolut. Fintech can be rough, it ain't all great, tread carefully. Oh and they delete feedback from forums if not positive lol
No bad experiences so far with Revolut, but will admit the customer support is pretty terrible. I had to enquire to the CS team about the top-up limit and ended up getting all of my answers from forums instead of the CS team.
I had a similarly disastrous experience with Revolut. I signed up with my US passport and everything went downhill from there. I was able to lodge €50 in to the account but couldn't verify myself (Revolut don't accept US passports as policy) and found myself in a awful situation trying to recover the €50. Revolut took two months to return the money to me.
I'm a massive fan of these apps though -- I use N26 personally . It works and I like that it's German (savings are guaranteed by German gov)
I actually had some issues with my old Revolut Mastercard with TfL. I asked them to check whether this was the case also with others, but no answer. I let this slip as I have plenty of other cards, but still.
After a couple of months, they acknowledged the issue and provided me a free new Revolut Visa. It still took about 2 months to get it in my hands, after having sent a couple of messages via Twitter.
Tbh I've been using Revolut for like 2 years now if not longer. Saved my ass whenever I was traveling, helps with geoblocked services, virtual cards are great and I can uses it with Google Pay. Never had a single problem.
This is, on one hand, great. I made the switch to a similar bank myself a few years back.
What I failed to realise at the time was how exposed I became to the vulnerabilities associated with being cashless. Cash is not just an ancient relic. Cash is an ancient relic and a fundamental component of a free society.
My country has, in practise, become nearly cashless and I used to be proud to be one of the very early adopters of that mindset. Now I lament how hard it is to deal in cash.
I am planning to switch to the only bank left in my country still providing personal cash services. The only one. That should be scary, not relieving.
A new-ish bank like Monzo mentioned above still allows you to withdraw cash like any other bank. You can't yet pay it into the account, but my understanding is that this will be provided pretty soon (based on their public roadmap https://trello.com/c/k2zy6WyU/98-cash-deposits-)
Cash is important, but I don't think it's going away any time soon.
And by "electrical outage" you mean more of a end of the world scenario? Because a normal electrical outage is not going to make your Monero worthless. It will have the exact same value before, during and after the outage. You need electricity to use Monero, but that can be also said about any credit or debit card.
I mean that I can promise to the merchant that I have monero I intend to pay them with but unless I can provide proof of this intention, by producing e.g. an IOU -- which will serve a purpose suspiciously similar to an official bank note -- they are worthless in the moments transaction.
What you are describing is also a limitation of Credit Cards and Apple Pay and Google Wallet. That does not make these things worthless either. Just wait a minute until power is restored.
Or pay in cash off course, but that only works if you remembered to go to an ATM first and that ATM had power.
Off course you could also write an IOU to the merchant about the amount of government IOUs that you will withdraw later.
I guess that means that your bank notes are worthless in the moments transaction if they are stored in a bank?
The actual secret API of banks-and by the way this is the initial strategy Plaid pursed if rumor is to be believed (essentially without the consent of the banks)-is by reverse engineering mobile app APIs. Most of these bank APIs try to use cheesy secret token vending to prevent casual API traffic on their endpoints, but the reality is that a sufficiently instrumented Android kernel (or rooted iOS device) will let you reverse engineer those protocols and masquerade as legitimate users.
Why don't banks sell API access at a rate s/similar/lower than Google Maps API access? This is starting to feel like music and video piracy all over again.
Because the value is in not being commodified. Not giving API access is worth more than charging for it.
If all of your credit lines, checking, savings, and investment accounts were an API call away, the institutions providing those no longer build relationships that can be profitable; they're simply utilities you could swap out interchangeably. As such, they're not a fan of this idea.
In crime we call it “organised” crime. I’m banking it’s just “doing business”. Maybe we should make this kind of invention of value out of thin air illegal?
Because they know they can't compete on a technical level with Amazons and Google's even dumping a billion dollars into tech growth, and disintermediation is a fast road to becoming a utility.
That rumor sounds far from plausible though. If they were to attempt to use the reverse-engineered API from their own servers without consent, banks would find out (in a matter of hours) and shut them down when they discover a huge spike in traffic from a relatively small pool of IPs. If they were to access it directly from customers' phone/browser via their (web-)apps, I expect that it would've caused a huge media storm by now when someone finds out they are storing/transmitting the password in plaintext (or its equivalent) to be used for authentication.
As for this instance specifically, I believe Chase grants Mint (and few other whitelisted companies) account access via OAuth. It's a step in the right direction, although it's not clear to me what their long term goal is.
Hi, I founded Level Money, was one of Intuit's earliest aggcat customers and one of their last customers, and did this for a lot of people until Capital One bought my company and we did it for them.
AMA, I guess.
But to answer the implicit question: shutting that off can be harder than it sounds. And because it's a mobile API and iOS's store has fairly slow update cycles, it can be very hard to simply rotate your API spec fast enough without interrupting customer service: a difficult thing for a bank to get away with (lol, I'm joking they're down all the time).
You've just banned every client coming from a workplace with a private network, every client on a commercial VPN service, and every client using Starbucks wifi.
Enjoy your customer service costs. On the plus side, bank have really good customer retention once they capture a customer.
Doubt over 5 people log in to a single bank from most starbucks over a 24 hour period.
If it's a big enough bank, the threshold should be higher. But they can easily pull the data and set a threshold that cuts off only the peak of the distribution
You'd certainly better hope so. A national bank going down is national news. You're gonna end up sending some muckety muck out to the press to bob their heads and apologize. They'd don't take kindly to that.
My prior investigations suggest that this strategy is ineffective. You suss out a ratelimit then pick a CSP and start spawning instances. Bonus points if it's a CSP that has a contract with that bank, they'll be petrified to try blocking you. Even well run consumer orgs can get tripped up with that.
But you're also suggesting that banks can use that data in that way or that that the relevant parties had the necessary capability at the time in question. Both are propositions you can make your own judgement on.
Here's another question: what happens when customers complain that you're cutting off their aggregtion service? You have your customer service reps say, "Sorry we locked you out of getting your own data?" Sounds like if you do that enough we have another press row. Thank goodness the CFPB was gutted, they loved 3rd party resale-to-consumer aggregtion services.
My belief is that organizations that can be gamed as easily as you describe have less than 1 fulltime person dedicated to preventing scraping. Or equivalently, 1 fulltime person should be sufficient to make it difficult to scrape at scale.
What do you think of the canary account I suggested?
> What do you think of the canary account I suggested?
I don't know how such a canary account would ever end up as a target for financial aggregation. It'd probably be a lawsuit from the aggregator for TOS violation if it was a sting operation.
They better be tracking logins or how do they investigate fraud? If they don't have a database of every login tied to an IP, I would assert they're negligent with regard to blocking fraud.
A lot of the measures taken to prevent fraud also block proxies and the like.
Re customer service: they say "here's how you can download your statements in pdf format", or for many banks in quickbooks/excel/etc format as well
I don't know how many of them had mandatory 2FA then, but I think many more have now. It would be far less risky to invalidate cookies on those high-volume IPs and force a new 2FA validation. Then legitimate users could reverify.
> They better be tracking logins or how do they investigate fraud? If they don't have a database of every login tied to an IP, I would assert they're negligent with regard to blocking fraud.
Look there are limits to what I'm able to talk about, but consider that a fraud subsystem functioning in transaction-time is running much more slowly than something running in request time.
> A lot of the measures taken to prevent fraud also block proxies and the like.
When was the last time you couldn't use your banking website over a proxy? Only a few mobile apps actually make the decision to do this (mine did) and it's not popular.
> I don't know how many of them had mandatory 2FA then, but I think many more have now.
Which national bank has mandatory 2fa? Not that this would matter. We dealt with 2FA at level via Intuit, that wasn't great at it. Plaid got incredibly good at it. It became pedestrian when we experimented with Plaid.
>Look there are limits to what I'm able to talk about, but consider that a fraud subsystem functioning in transaction-time is running much more slowly than something running in request time.
I was suggesting checking one day snapshots of access counts by IP to see what the distribution looks like to then determine what to block.
2fa: I know that chase asks me for 2fa every time I change IP, and I don't think there's a way to stop that. Should be easy for them to require 2fa on every login for any IP with a high rate of requests.
If it's in the binary Simple ships I can take it or modify it to not need it. It's a huge pain in the ass, but it's not "hard."
And while I know I did a cert pin and you did a cert pin, not everyone does it (or does it bidirectionally). Nor is that the only way folks would get an API spec.
This is very clever but makes me sad. It’s 2018 and the best, cleanest way of monitoring and storing my own transactions programmatically is by scraping an email.
Banks provide an API in Europe. In fact it's a legal requirement that's coming into force in 2019, and there are a lot of 'mobile-first' banks like Monzo and Revolut which make this entirely un-needed in the first place (providing spending exports, decent analytics, push notifications, etc etc).
Welcome to the future. Contact your local politician if you want to join us. Maybe also ask about chip and pin while you're at it!
> Since you're so far in the future, can you consider dragging Germany into it as well so I don't have to use cash everywhere I go?
I think that stems from an intense dislike of debt, specific to Germany more than anything.
Not sure why that's relevant to my comment though, or why being 'so far in the future' means 'credit cards everywhere at all times'.
Also the USA is still using cheques. They haven't even got to chip and pin yet. We are pretty much past that and onto contactless. How is that not futuristic compared to squiggling on a bit of paper to verify your identity?
"Also the USA is still using cheques. They haven't even got to chip and pin yet. We are pretty much past that and onto contactless."
I'm not sure what you're talking about. All my cards have chips, and I'm in the US. And for several years, I've been living in an apartment which takes direct bank transfers for rent rather than paper checks. Landlords in my experience have been the last holdouts that don't want to stop using checks. Contactless payment I don't use, but I know it exists in the US because I see signs when I check out.
Businesses still use a ton of checks, too. Even if they have direct deposit for employees there's an absurdly good chance that they're paying all their vendors with a paper check. I still don't fully understand why this is still the case, other than there not really being a compelling reason to change a system that works fine.
"until recently" meaning several years ago? Availability of terminals and support for the chip was what lagged, not the cards themselves (though that's a semantic argument in this case).
I would also somewhat argue that "most" cards are chip and signature, not chip and PIN. While in the US my cards all prefer PIN, it wasn't until I got out of the US that for some reason they all wanted a signature - talk about irony.
It's still far from ideal and not nearly as rigid as it is in Europe, but it's not quite as bad as you seem to think it is.
Is this really a characteristic of the card, rather than the reader? After all, my cards have pins. And often neither a pin nor a signature is required, although the chip is read. And when I buy something online, obviously the chip is not read.
Landlords have been the exception that demonstrates the rule, was my point.
Even landlords who are notoriously cheap and low-tech, are moving away. So called checking accounts don't give you a free checkbook any more, in my experience. I don't think I've had to wait for a person writing a check at the grocery store in the last 20 years.
I don't think some landlords requiring checks (in my case almost a decade ago) mean the USA hasn't moved away from paper checks in general.
People often generalize one group by the actions of a tiny fraction of its members, while comparing to another group characterized by the actions of the vast majority. It was particularly blatant here.
> Banks provide an API in Europe. In fact it's a legal requirement that's coming into force in 2019
That's simply not true. You're probably referring to PSD2, which is not an API in the sense that anyone technical would use the term. And it's not meant for you or I. The requirements for gaining PSD2 API access are insane, and at least in some areas require permission from the national bank. Which you won't get unless you're a large corp with big bucks and lots of insurance.
Sure, but as other users like Rjevski have pointed out the PSD2 API is going to be nearly impossible for the common person to use. Unless you want to become pretty much PCI-DSS certified.
So you're surprised or concerned that applications that wish to extract financial data abour consumers programmatically from their bank accounts need to conform to regulations regarding the storage of said data?
> API is going to be nearly impossible for the common person to use
Reading what you are replying to and making an argument against that rather than a hypothetical straw man that GP didn’t imply or mean will get you further.
More importantly, the original post, the one you responded to somewhat arrogantly, stated:
> This is very clever but makes me sad. It’s 2018 and the best, cleanest way of monitoring and storing my own transactions programmatically is by scraping an email.
It would seem that, outside of Germany, which has FinTS, the cleanest way to monitor my own transactions programmatically may well remain email scraping.
Looking here[0], it seems the future is fake, and the EU is no better than the US in this regard. Even after 2019, I'll still have to scrape bank's website and manual exports to get my own data out in usable format.
I talk to (about) a person a week who wants to create a new US bank. Some are pursuing a de novo charter, some are buying a bank, and some are a quasi bank on top of another bank.
The real blocker here is the Fed won't grant new charters and often won't transfer charters. I'm hoping this will change in the next few years and we can get some real competition.
What's your take on new entrants at the processor level?
When I worked for a debit card startup (stripe's new feature, but worse, and years earlier), it seemed like the "bank account" parts were mostly boring money buckets, and all the interesting features existed at the processor level.
FIS was tragicomic to interface with, and they control something like 50% of card swipes in the US if i understand correctly?
Seems like if you want to make a really major play, you do to FIS what stripe did to paypal, right?
I was expecting this to outline how you could actually use various APIs from different banks, but was still pleasantly happy with the actual content of the article. This is a clever idea I had never thought about doing. Kudos to OP!
Uber is popular everywhere, including throughout Europe.
And as for banking, well, it's somewhat worse in the USA than elsewhere but it's not like Europe is overflowing with awesome hi-tech banks. Yes there are a few "startup banks" in the UK and one in Germany that I know of, and that's about it for the entire continent. Moreover the vast majority of people don't use them and bank with the existing set of firms, many of which have legacy and decaying IT estates. Look at what happened with TSB recently. Total meltdown. Major IT outages in the UK banking sector have become commonplace; you don't hear about that happening in the US.
TBF in Europe (or specifically the UK) the new regulations seem to have come up with a plethora of new banks -Starling, Monzo, Revolut, Tide, etc.
Both my personal and business accounts are with these, and it's awesome. Starling for my personal account and Tide for the business one. I get notifications of payments usually before the in-store machine has finished sorting itself out. Also get nice things like being able to use Google Pay before the card arrives. I've just got married, and our joint account will be one of these.
I assume these banks have popped up from these EU regulations, as they didn't exist 3 years ago.
Not from those EU regulations - PSD2 is more recent than most of those challengers. They've popped up because the FCA (the UK regulator) deliberately tried to make it easier to start banks in order to get more competition in the space.
No, the financial services industry needs some serious disruption. Banks need to be MORE conservative. Not less. "Disruption" in banking is whats caused previous financial crisis.
Managing user interfaces to sell financial products is not the same as running a bank. This is why API's are so important. They allow innovation in the sale of financial products while keeping the actual risk calculations on deposits and loans heavily regulated.
Of course, banks don't like them. In the same way internet providers don't like net neutrality. Nobody wants to be commoditised. But this segregating of responsibility is the only way you can ensure positive change for consumers/businesses without introducing a bunch of risk into a critical piece of the economy.
I want my bank to offer me the ability to generate Access Control Lists, with generated accounts. I want to make an account with read-only access to all of my financial information. I want to monitor all of my assets in real time, with alerts going to my phone for suspicious activity.
That's MORE conservative. But it's only enabled through intelligent APIs, which banks in the US don't have. With Mint, you passed over your full banking credentials, which was absurd.
I'd also like to remove the ability to PULL money from my credit / debit cards. I want only to PUSH money from my bank. Allowing companies to pull is what allows the vast majority of identity theft.
That's the kind of disruption I want.
Give ME the control to organize, monitor, and control access to my funds.
- Universal, near-instantaneous per transaction alerts. It helps stop fraud right away rather than after-the-fact. It also helps solve problems while they are fresh rather than trying to resolve a month-old+ issue. Some countries overseas do this almost universally.
- On-restaurant-table credit card swipe rather than taking the card away and entering tip later. Many places overseas do this almost universally.
-- Side note on the txn alerts:
I suppose it is due to the way Visa/MasterCard are processed, but I sometimes get alerts a day or more after i've done a credit card transaction. Some cards dont even have the option for alerts.
AMEX has great alters, almost instantaneous, but I suppose they control the entire stack, so that makes sense.
In the US, almost universally, they take the card away. Swipe it somewhere in the back -- without a PIN. Then bring back a receipt for an inked signature, which is supposed to the be the alternative to a PIN.
Oh, and you put the tip in on that receipt, and they go back and do a second entry of the tip (sometimes incorrectly, almost always higher when incorrect.)
Worse - the transaction alert -- if you get one -- is the pre-tip amount. Makes no sense.
FYI if they enter the final amount incorrectly you can dispute the charge with your credit card provider. It's probably a stronger case if you kept your own copy with the final amount that you wrote down.
It is if you want to solve the problem across the board, rather than having a niche system that a small handful of vendors use that just introduces one more surprising variation at payment time.
I disagree entirely. The problem is that the US banking industry permits this state of affairs. They should require updated, at-table point-of-sale devices within a reasonable timeframe to be able to continue to take credit cards.
It always seemed odd to me that the card readers are owned by the retailer. On the one hand, that leads to a lot of old or insecure-by-design equipment in circulation as 'not worth the cost to replace", and on the other hand, it tends to lead to a lot of annoying spam calls of "we'll replace your machine if you switch your payment processing to our company."
If the upstream providers provded the readers as a leased service instead-- maybe for a few dollars a month-- they could push out insecure gear in a timely manner more aggressively. Just reject connections from old devices because everyone renting the old model has been sent a new one already. It would also eliminate the price of equipment upgrades as a leverage for competitors to peel off customers.
From what I can tell, the machines are fairly locked to the service providers, and require fairly intensive setup, so it's not necessarily like an unlocked phone where you'd save money by buying a device independently of the service.
If I want to make my financial life difficult in the sake of security, that should be my choice. I'm sick of banks saying, either implicitly or outright, "we don't want to ratchet up security measures because people will find it inconvenient. You can say that because it's not your money on the line.
Why can't I ask for chip-and-pin or nothing? No chip-and-signature, no swipe-and-pin, no swipe-and-signature,no it's-less-than-$50-so-nobody-cares-and-we-don't-even-ask-that.
Why can't I have a card inactive by default-- if not used in a week, you have to press a button in the app to re-activate it before it works again? Then you could potentially add "the next charge will be $120 +/- 10. Those would make for a smaller target for spray-and-pray fraud.
Conversely, when they do try to protect you, they do a terrible job of it. My bank (one of the largest in the county) has a particular hard-on for the website of a large regional electronics retailer. In person, fine, but if you order from their site, odds are 50:50 it will fail and your card will get fraud locked. I am significantly less likely to order from them because I know it's going to be a hassle, even when I see an offer I want. If I could white-list the merchant, problem solved. If many customers whitelist them, it might provide better information for their automated anti-fraud systems.
"I'm sick of banks saying, either implicitly or outright, "we don't want to ratchet up security measures because people will find it inconvenient. You can say that because it's not your money on the line."
But my money is not on the line. That's what a credit card is - I'm using the bank's money, and I am not charged for fraud. If the bank was seeing excessive amounts of fraud, they would ratchet up security measures.
However, any security measures should be treated with skepticism - do they measurably increase security, or do they serve merely to transfer responsibility away from the banks?
"Why can't I have a card inactive by default-"
You can get single use numbers on many cards, which I think would solve your use case.
Well, I tend to think in context of a debit card, but covering your ears and screaming "zero fraud liability" doesn't solve everything.
You're still incurring costs and hassle getting your account detangled after a fraud, and the trouble for getting the cards reissued. The bank itself is going to have to deal with the costs of insurance and payments it was unable to recover. Eventually, somehow we're paying for that in higher fees or worse rates.
It also tends to undermine the fundamental legitimacy of the bank. Remember when banks tended to be big free-standing buildings with huge visible vaults? The message was "we're keeping your money safe." Not "we don't keep it safe, but we have really awesome insurance when we inevitably mess it uo!"
- Instant, ultra-low cost inner-bank transfers. None of this "wait a day (or more)" ACH business or "send money via paypal, but then have to wait a day (or more) to ACH it into a real bank account". Useful for everything from paying friends back to moving money between two personal accounts.
I assume you mean inter-bank. Many US banks do instant transfer between accounts in the same bank, even if different account holders. On the inter-bank front, there’s Zelle that many US banks support that’s instant and free, but it has stupidly low limits. On the kinda instant front (aka under 15min), wiretransfers exist but they are a poor UX universally and have a steep fee generally (my bank does it for free, but I have to have a high end account for that).
I guess it's not popular or all that well-known anymore, but for quite a while there's been a Quicken-led banking interface for some banks. Known as OFX or Direct Connect, it provides at least one-way (download) access to banking transactions. I think there's a way to upload as well but have never used it nor had a bank that supports it for upload.
My bank has a separate enrollment - it was free - offering download-only access to my transactions. I haven't used it in awhile (just too much on my plate) but it worked well as recently as 2016.
It's often called "Quicken Direct Connect" (NOT "web connect", that's a bastardization trying to push the login flow through the proprietary web interface), and often has to be specifically enabled for your account (Bank of Slum-merica is the only place I've heard charging for the functionality though).
Setup a cron or human cron to pull and save the raw OFX (QFX) query every day/week/month, and then run whatever reports/analytics you want from that. This way you'll have history to use with whatever program/scripts you move to, and can also straightforwardly integrate legacy banks that make you use the web interface (just at a much lower polling rate).
I don't exactly know. But I'm under the impression that it performs the standard website login flow via headless browsing, then uses the website's "download transactions as OFX" functionality. So similar problems as "screen scraping" but less error prone because if it successfully downloads the data, it is in a well-defined format.
I used OFX for quite a while. Had a home-grown pile of scripts that did my budgeting/record keeping, and even reverse-engineered their payment submission system, and had nearly everything semi-automated to my personal satisfaction for a while.
And then they revamped everything, sprinkled security (and "security") pixie-dust around, and I gave up after locking myself out repeatedly trying to jump through the new hoops.
This is an awesome alternative to scraping your own bank transactions. I'm considering using this technique to automatically add rows to my personal GnuCash MySQL database.
Sendgrid has an inbound parse feature (https://sendgrid.com/docs/User_Guide/Settings/parse.html) which you can use to start building a framework - it takes any inbound email to a domain and forwards it as an HTTP request to an endpoint you specify. Used it for a few projects and its worked great.
It’s a full framework for handling almost everything a MUA would do (imap/pop, email parsing, mime parsing, sending email, etc), so yeah, it can do that. You’ll have a bunch of boiler plate code you’ll need, but a Google search will give you plenty of samples.
Posts like this make me pretty excited to be a customer of a "tech-y" online bank. (In my case, Simple, not shilling, I just like them)
Theoretically, these banks with great mobile apps are one step away from giving you API access once it's needed/wanted by enough consumers. Technically, your phone is doing it under the hood already.
Simple uses React for their web interface, so I imagine they have nice JSON APIs for all of the data already.
There was a site advertising developer managed bank accounts last year, https://root.co.za/, I think it's also a cool idea.
You can prod the network panel to reverse engineer simple's APIs. I've done it for some visualization tools in the past.
It's sloppy and undocumented, but their support staff are fantastic and surprisingly technical, so I had about a 100% success rate tweeting them things like "what's the new endpoint for what was previously /bank/transactions?"
A public version of this API was one of their stated goals in 2010 or so, but they're more interested in chasing non-technical product goals like couples accounts. I expect their most technical customers don't make up enough transaction volume to justify attention.
I love simple for being the least worst, but am still saddened by what they could have been if they had stripe's passion for technical execution. But hey, at least there's an API and they won't slap you with the CFAA for hitting it.
I tried doing something like this, but it didn't work for Bank of America, as their minimum alert level is $100.
When I lived in Slovenia, I could set SMS alerts from my bank there (UniCredit). I wrote an Android app [1] that intercepted those SMS messages and parsed out the relevant bits. Those were the days...
> I wrote an Android app [1] that intercepted those SMS messages and parsed out the relevant bits.
Sounds like a nice hack, but at a meta level, I find the idea that a mobile platform even allows an app to ‘intercept’ SMS messages to be a little troubling.
Well, it doesn't. You have to do a lot of things in order to allow it that it's impossible to not know exactly what you're doing. I think it's positive that I am in control of my device when I want to.
1. In order to achieve this functionality, the app explicitly requires permission to receive SMS [1] [2]
2. I agree that the general population likely isn't fully aware of the implications of granting permissions for such things. Having said that, I think that privacy/security/transparency is one of the things constantly being worked on with subsequent Android OS updates [3] [4], and I think that things are getting better.
Personally, I don't grant access to sensors like microphone/camera/location to apps that I don't want using them (most apps), and I think people should be aware of potential hazards here. Then again, people are openly inviting Amazon Alexa and Google Home into their homes ...
On the other hand, as a developer I like having the ability to build this, for me, and potentially for others who find use for what I wrote, with full transparency/visibility into the source.
There's so much cool stuff you can do with this data. Think of all the creepy shit amazon does with your browsing data, but for your spending data, and you can browse it.
We're leaving a crazy amount of insight on the table.
Shameless plug: I built some personal finance viz tools based on similar data. they also just barely scratch the surface: http://rick.xxx/orchid.html
If you're working on interesting things in the fintech space, I'd love to chat with you about strategy or execution, especially w/r/t product design. Email in profile.
Forgive the shameless self-promotion, but we at Seed offer a customer facing API for read-only transaction data. We would happily build out more API features, but we've seen very little demand, despite the frequent HN threads about bank APIs.
We are a business focused bank, but we support sole proprietors and freelancers as well.
It's really unclear to me what your product is. I would have given up trying to figure out if you hadn't implied that it's somehow related to what this cool blog post accomplishes.
From the FAQ, my best guess is that you offer businesses bank accounts that come bundled with the reporting you'd get with something like Mint/Quickbooks?
It's OK to basically be two services glued together, but why are you better than just the two existing services, were they to be glued together?
You may want to try plaid. They've integrated every major US bank(and some CUs) either using bank api or scraping their web pages.
You can get not only transactions, but also account info, balances and enough info to perform charges/payments(e.g. ACH routing/account numbers). Api is no-nonsence and they got decent dashboard.
Its paid service, but they allow 100 accounts for free(you need to apply though). To check what are major banks they support, you can visit their status page: https://status.plaid.com/
Yeah, I've been doing this for a couple of months now. I just happen to use a combination of Gmail filters, IFTTT actions to post to a webhook of a custom app hosted for free at Heroku to parse and send to Google Spreadsheets. It's been serving me well, definitely better than my bank's app.
Not original commenter, I used to use and like them, but at one point they changed all URLs to use their shortener (I was using it to archive all links I post on FB into an Evernote note). Great, they want to do more analytics and they're making sure all URLs in content they're supposed to be just plumbing will die with them, very customer friendly.
Thanks but I'm aware of Zapier. The custom app is fairly easy to maintain, I can keep track of changes and it provides total flexibility for my needs in terms of parsing and how to store the data.
I just spent 20 minutes reading about the fascinating case of Ellis vs. Grand Rapids, as linked from the poster's site (http://gduverger.com/ellis-v-city). This was like a two-for-one deal, so thanks!
I've been getting a good amount of requests for open sourcing it. It would require a few hours of work but I might take the time one of those weekends. Please feel free to send me an email (georges.duverger@gmail.com) if you'd like me to keep you updated.
I've had to do something similar when a bank decided that CSV history was limited to a much shorter time period than PDF documents. Nothing a little python-driven OCR can't handle. But it was stupid I had to employ such measures in the first place.
Many banks do not actually include any information in the notifications, because of the unencrypted nature of in-transit email. That is, "There has been a debit on your account" instead of "There has been a debit of X$ from merchant Y".
For the 0.001% of Nanking customers who understand PGP, let alone who can set it up. Yes, I’d love it too, but until PGP is more user friendly for the masses, I wouldn’t hold my breath on any bank bothering.
So, he does not trust third-parties with his banking details,
but uses a third-party to send emails with a complete detail of his account to an email-server (which might or might not be run by a third party).
The logic is lost on me.
Furthermore, the e-mails are sent in clear-text and readable by any endpoint on the way transporting the e-mail to its destination. It's akin to sending your information back to yourself by post card rather than stored in a file with a third-party.
The alert emails do not contain “detail of [my] account,” only the last 4 digits of my account (for Chase). Even if someone were to intercept those emails, they couldn't do much with them.
TBH, the only “unwanted” transactions I’ve found were indeed fradulent, and these have been immediately caught by BoFA, VISA, and other financiers. I have had problems with false positives, however.
People would normally call out fraud if that were the case, but it's certainly possible that it's something the bank isn't aware of yet so their systems did not catch.
In general I just assumed he meant things like "signed up for that trial and forgot to cancel", "accidentally got charged twice", "tip amount was clearly wrong"... Innocent things that happen from time to time, but clearly need to be resolved.
Are the bar charts generated with the pandas library? The ones in the report received by mail... Took a peek at the documentation but all I see is graphic based ones with plot functions.
Thanks
The bar charts are my own, not part of pandas. I wrote a little thing for it. It's not very sophisticated right now but I've been thinking of packaging it a little bit better and maybe sharing it.
I'm so happy to be a bunq user (which is a Dutch bank), they provide a fully featured and easy to work with API to do and build anything you want. Other banks should follow.
Bank Millennium is a normal Polish bank, with branches everywhere. Their mobile app gives me an instant notification when transactions occur. They even have an Android Wear app.
Irrelevant but also impressive: their app uses fingerprint login and whenever I phone them they talk to me in English without me having to ask.
Look into OFX for pulling down account and transaction data It’s the api that TurboTax, Quicken, and others have used for years and you can use it too. It’s a little outdated in its design and implementations are hit or miss on the banking side. But for most large banks it works.
My bank allows me to export my account statements in SWIFT MT 940 format, which is pretty convenient. Sadly there's no easy/free way to automate this process.
I've been getting a good amount of requests for open sourcing it. It would require a few hours of work but I might take the time one of those weekends. Please feel free to send me an email (georges.duverger@gmail.com) if you'd like me to keep you updated.
That really depends on your threat model. If someone already has access to your email account it's game over anyway most of the time. I don't see much of a problem there if you are not worried about your ISP / mail provider taking your data.
https://thenextweb.com/worldofbanking/2018/06/27/openbanking...
Already right now in Germany there are a lot of banks that share a common API format which is why there are a lot of banking apps where you can just log into your bank and don't need bank specific apps. It's called HBCI / FinTS (https://en.wikipedia.org/wiki/FinTS) and it's great to have that possibility without doing some web-scraping to get your data out.
One example of another german bank API would be:
https://api-docs.fidor.de/v1/introduction/welcome-text