The Secret API of Banks
gduverger.com
gduverger.com
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:
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.
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.
- £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.
- 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 ?
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).
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...
Where do you draw the line ?
[1]: PSD2 https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELE...
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.
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.
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 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.
1. https://en.wikipedia.org/wiki/Application_programming_interf...
That isn't true. Anybody which wants to be in the UK Open Banking Group (mandatory for the 9 biggest banks) must follow these very strict specs:
https://openbanking.atlassian.net/wiki/spaces/DZ/pages/16385...
A number of the CMA9 were given a deadline extension, so there is no reason for them to be compliant yet.
Why is this a problem exactly?
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.
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 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.
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?
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.
> 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.
This is not actually a real world problem though. If it were it would likely be addressed.
Why do so many people think only in theoretical extremes?
It is, people often get scammed into giving access to their accounts. Having more locked-down APIs is a way to move off from this.
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?
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.
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.
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.
In that case, let's get rid of cash, cards, and frankly everything, because otherwise scammers will take advantage.
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.
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.
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.
It's open, just not the "open" you imagine. Like anyone from the street being allowed to do it.
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.
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.
Which is a big deal in 2018 and the era of open data, data portability (even Facebook offers data exports). Why don't banks offer data exports?
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.
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.
Am I really asking for too much?
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.
[1] https://medium.com/wibson/how-much-is-your-data-worth-at-lea...
[2] https://www.offshorecompany.com/banking/start-a-bank/your-ow...
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.
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.
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.
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.
Really makes you manage your money better.
They seem to know what they're doing at least
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)
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.
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.
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?
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.
It's sad, because that's exactly what they should be. :/.
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.
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 can also use your own canary accounts, provide them to the service you want to block, and ban any IP that tries to log in
Enjoy your customer service costs. On the plus side, bank have really good customer retention once they capture a customer.
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
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.
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.
>lawsuit
You really think an aggregator who's blatantly violating bank TOS is going to sue?
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.
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.
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.
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.
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!
I personally use the API to automatically add flat bill directly to Splitwise.
[1] https://monzo.com/features/ifttt/ [2] https://docs.monzo.com
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?
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.
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.
Several years, huh?
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.
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.
Oh no. What a travesty.
> 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.
> 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.
that's generous.
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.
--
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.
(Disclosure: my job is making APIs for US Banks.)
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?
What about doing a state-by-state charter?
One of the ills of VC-mania is the ongoing assumption that a) problems that exist in the US exist everywhere and b) that there are no other problems.
(see also: Uber busting the "taxi monopoly")
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.
- Extremely high starting capital requirements (10-100 million USD)
- Knowledge on security, finance, and law, means you will be needing an expert team of lawyers, accountants, cryptographers, etc.
- An actual location and strictly controlled building to keep the physical money.
There are a lot more requirements but the first 3 make it almost impossible for a lay-man to start their own bank.
A better alternative to starting a new bank is buying a small bank. It may actually be cheaper than starting a new one.
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.
- Extremely high ($10 billion plus) market opportunity, with a ~0.1% to ~1% capital requirement.
- Recruit a team with the highly diverse skills needed to operate a modern bank.
- Have a secure location? Let us pay you to leverage assets from another startup.
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.
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.
If they took the card away, how would you enter the card's PIN? That's why places outside the USA do the swipe on the table.
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.
This isn't a problem you can solve by changing the banking industry. This is a point-of-sale problem.
It's all part of a larger set of "problems with US financial services". The fact that it is technically different vendors is not relevant...
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.
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.
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!"
- ubiquitous NFC-based payment systems
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).
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.
https://github.com/aqbanking/aqbanking is one open implementation for the interface.
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).
Check say https://ofx-prod-filist.intuit.com/qb2600/data/fidir.txt to see if your bank is listed (that contains both direct and web connect banks, you'll figure out what the flags mean).
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).
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.
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.
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.
How are you doing authentication for the API? Is it session based or can you pass some sort of API token after logging in?
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...
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.
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.
[1] https://github.com/loisaidasam/poor-mans-money-counter/blob/...
[2] https://developer.android.com/reference/android/Manifest.per...
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.
We are a business focused bank, but we support sole proprietors and freelancers as well.
API docs are here: http://docs.seed.co/v1.0.0/docs
p.s. We are working on Android I promise please don't yell at us (again).
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 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/
Here's a link to http://Zapier.com
And then there's this: https://blog.pinboard.in/2016/03/my_heroic_and_lazy_stand_ag...
So, it's not too far fetched.
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.
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.
It's the one pixel gif of systems integration.
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.
I suppose if my # is lifted and $0.01 is used as the test transaction it would sneak by, but oh well.