3 ms·

Disclosures: I work at Ally and my team is building Ally's new online banking interface. - Unlike Simple, Ally is actually a bank. - We take deposits and then

Disclosures: I work at Ally and my team is building Ally's new online banking interface. - Unlike Simple, Ally is actually a bank. - We take deposits and then turn around and lend that money out primarily as auto loans. - The rates we can pay are currently capped because we're still a TARP company. Interface-wise there will be significant changes in the future (October-ish). Our entire online banking will be a single page application built using Ember, inspired by Simple. The transition will be ... interesting ... but after things settle down you can know that we're aiming to compete at least interface-wise in the space that Simple is in. (They have some fun things on the backend that we're not attempting yet.) And if you look under the covers once we launch you'll notice that there is an API driving nearly everything. I wonder what might happen if that were, say, usable by others?

cmelbye 13y ago
I'm interested, what kind of stuff are they doing in their backend that you guys aren't going to attempt to do yet?
- nathanhammond 13y ago
  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/ http://www.fisglobal.com/ Fiserv - http://www.fiserv.com/ 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 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."

cmelbye 13y ago

I'm interested, what kind of stuff are they doing in their backend that you guys aren't going to attempt to do yet?

nathanhammond 13y ago
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/ http://www.fisglobal.com/ Fiserv - http://www.fiserv.com/ 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 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."