| This is an over-simplification. I'm also not entirely sure how much I can say, so I'm skipping things. Most banks use what we term "bank-in-a-box" software provided by one of two vendors: FIS - http://www.fisglobal.com/
Fiserv - http://www.fiserv.com/ In fact, just about the only ones who aren't using a complete bank-in-a-box solution are the megabanks, for example: BofA, Wells Fargo, Chase. The upside of using a bank-in-a-box solution is that you can spin it up almost immediately and at very little cost (relatively). The downside is that you're running technology that, very often, was written last decade. For example: https://secure.ally.com/allyWebClient/login.do uses jQuery 1.3.2, released in 2009. But worst of all, you can't really differentiate yourself from your competitors–they're using the same thing under the hood. In order to begin the process of differentiation you typically see banks progress through stages out of dependence upon these solutions. 1. First you enable service calls into the system of record (SoR). 2. Then you Balkanize your services, calling back and forth between your BiaB solution and your own custom component which reaches out to the SoR through services instead of the hosted, white-labeled BiaB. This is terribly slow. Remember what I said about last-decade technology? 3. Eventually a bank completely migrates completely to service calls on the backend to the SoR. But they still haven't implemented any of the reporting or back-of-house processing. 4. The ambitious banks then start trying to move the SoR and the back-of-house processing and reporting (this is a big deal) in-house. However, to work, this has to be a one-time switchover since "eventually consistent" is not a valid state for bank data. Almost everybody stops before attempting Step 4. It starts getting expensive and hard really fast at that point–and almost no bank has that appetite for risk. However, even if you attempt Step 4, the legacy of your technical decisions has resulted in loosely coupled and often poorly integrated experiences wherein even pulling your data in-house likely doesn't fix it. At this point Step 5 is digging out of your technical debt, and I've yet to see any bank succeed at that. Simple skipped Steps 1 & 2. They never incurred Step 5. They were insulated from Step 4 by using a holding bank. Step 3 was why they took so long to launch. On a technical level Simple is years ahead of every bank out there. Features they had the data for could be implemented in no time. Organizationally their mission was clear enough that everybody bought in. Their race, which I've said numerous times, was to catch up to Ally's marketing and deposit assets before Ally (or others) catches up to their technology. It's an asymmetric race, but not being a bank means that Simple couldn't leverage fractional reserve banking to its fullest which cuts into profit margins and makes it much harder to succeed. Their acquisition price implies to me that their burn rate was too high for their revenues to make the long game sustainable. Contrast with BofA: "We spend, just overall, about $3 billion and change in annual technology development." |