|
|
|
|
|
by jswny
3284 days ago
|
|
Not only does this sound potentially illegal but how can you be confident that you will recognize the breaking changes in time to fix them? What if you begin supporting a large number of banks and you can't keep up? Also, will your reverse-engineered use of the mobile API's have any detrimental effect on the user? I imagine the user will be the one authenticated with the API, what if the bank starts to see an influx of odd API traffic and decides to investigate it or there is some type of rate limit? Your decision to reverse-engineer mobile API's opens the door for many important questions in my opinion. |
|
In terms of stability. It actually takes 6-12 months for a bank to get something into production. We are not talking about fast moving organisations here. We have not had a breakage with a supported integration in two years of beta testing.
We take many steps to ensure our traffic does not stand out to banks eager to actively interfere with Teller. Our clients perfectly emulate (100% API compatibility with their own) and make the same API calls in the same order etc. We also only make API calls as a result of user action, i.e. Teller does not poll or cause atypical traffic patterns. Finally have 100s of IP addresses and assign an IP address to a user for a period of time. All of this compounds to make Teller traffic look indistinguishable from their own mobile app traffic. The objective is to make it more likely they will block their own app traffic than block Teller as a string incentive to not interfere their customers' choice to use Teller enabled services.