Banks choosing to build and not buy tech, suggests survey

this should be debated as there are very strong arguments both ways. This is not a 'light' decision.

Find this a surprising result as even banks such as JP Morgan have recently chosen to outsource more, not less. In the war for (IT / tech) talent banks face already an uphill battle and now they are going to build more tech in-house? How? With whom? Especially in the fields of AI and other more "hot" fields.

Equally surprised - the global trend to consume IT is to pay as you go on subscription, cloud based and flexible to move around the sourcing so you can ensure you have expertise on hand. Will need to dig into the data used by NTT as seems at first read to be an outlier.

Agree with the above - NTT should send us the report. I would be happy to review it. 

Highly surprising, does anyone know what report this might be from? Is there a way of finding out?

https://www.information-age.com/majority-of-banking-institutions-building-their-own-technology-stack-123499743/ 

There's most context in this article. Scope of figure is narrow. It's specifically for advanced cash-forcasting solutions. Probably not as generalizable as it's made out to be. 

I am not surprised by this data, even if it is limited. In our experience, we can see the banks are desperate to become more tech driven. Will they build the stuff they are now choosing not to buy or rent? Highly unlikely. 

The article may genericise a spot observation, but it raises a good question nonetheless. The old adage of buy-not-build does not particularly wash when: 

- You customise a lot of what you buy, meaning that you custom develop while making your life harder working in  the constraints of a package

- What you buy has considerably more capabilities than you need (or many overlaps with other packages already in place). A sure way of complexifiying rather than simplifying your architecture

- The integration spaghetti between the packages and the data alignment become the real nightmare

- The real cost is the cost to change when banks need to adapt quickly. The buy-not-build mainly applies in a cost to run perspective where change and differentiation is not the main driver.

Kaizen thinking takes the very pragmatic view of building to just your needs and assessing carefully when product/SaaS provides advantages. There is some value in this perspective. 

With this said, products like Thought Machine take an open perspective (smart contracts for product definitions), which make them very customisable / extensible. That seem to offer the happy middle and I guess they'll be doing very well indeed.

Lets be clear, Banks are not "tech companies". Few if any protected software IP and none that I know of sell software/cloud services. Providing banking capabilities in the cloud that require a banking licence does not make them tech companies. Running a bank and a tech business are two very different things...

I'm not surprised and it confirms what we have experienced in the market. Note that this survey is related to cororate banks and not retail banks. Corporates expect banks to meet their specific needs and if not, they switch to a bank (or Fintech company) that can. Large corporate banks have bad experiences in being locked in by 'closed' system from software vendors. When the bank wants to implement a specific feature that the vendor's product doesn't cover, it completely depends on that vendor to have it added (or not). To avoid this dependency, an increasing number of banks has plans to build their own technology stack/frameworks on basis of which they can build their own specific functionality. But this is easier said than done. Building a mature and proven framework takes easily 4 to 5 years before its is mature enough for a widescale implementation and requires many millions of investment. Not mentioning the risks of failure or rework that comes with it. But there is also good new. New generation technlogy frameworks from vendors offer banks the best of both worlds. The bring a proven, mature and ready to use domain (e.g. payments) specific frameworks with a large amount of out-of-the-box functionality, but based on an open architecture that allows the IT team of a bank to add the bank's own specific functionality/features without being dependent on the vendor. This approach saves the banks a lot of time, investment and risk, but at the same time offers the same amount of flexibility and vendor independency as a complete self build from scratch. Interested? Please, do not hesitate to contact us. 

To say I am surprised would be a euphemism... We have been getting a growing number of requests for neobanking and digital banking software, plus quite a few companies were interested in core banking solutions... 

While selling COTS software to various industries, I've observed that the banking industry typically demands more extensions, customizations and interfaces (ECI) than most other industries.

In both onprem and SAAS models, product owner advocates against ECI.

That doesn't matter much in onprem model, where there are any number of third party service providers (including some of my ex-employers) who gladly do the ECI work e.g. Accenture, TCS, Wipro, et al. 

But in SAAS model, especially multitenanted SAAS, the product owner has much tighter control over the codebase and third party service providers reportedly can't do much ECI. 

Now, onprem or SAAS, banks are banks and cannot live without ECI, so it makes sense that they'd resort to BUILD rather than BUY in the SAAS world of today.

That said, even in the onprem world, while small and medium banks adopted BUY, large banks have typically resorted to BUILD in Trade Finance, Cash Management, Treasury Management and other areas of Commercial Banking. As testimony, many large banks still run very old homegrown COBOL legacy systems even today. Also, there are large banks who bought COTS software in their emerging market subsidiaries but built custom solutions for their HQ and subsidiaries in developed markets. 

• Effective built solutions typically require a dedicated team, meaning you’ll have to permanently move developer talent away from current projects or hire additional hands.
• Contrary to popular belief that building software in-house will pay for itself over time, the majority of software costs go toward maintenance, not initial development—requiring interminable recurring costs for IT Coding and a dedicated support team.  
• Building in-house can also be a risky endeavor, prone to both cost and budget overruns.   
• Buying pre-built software removes this risk and any costs associated with maintenance are built into your contract to avoid any surprises later on.

Yes with in-house solutions, you have unlimited flexibility to create a product that meets your goal however AML Partners award-winning RegTechONE is built to be a NOCODE Platform where changes are easily possible at UI; hence no costly surprises.