Home > Blogs > Building compliance with enterprise-class components

Building compliance with enterprise-class components

September 18, 2013 - Jaymalya_palit


Does the banking sector really need more regulation than it already has coming? A UK IT trade body is proposing ‘enforceable infrastructure standards’ after an IT disruption in one of the country’s premier banking institutions financially excluded many customers for almost a week.
The process of regulatory introspection unleashed by the 2008 meltdown holds enough promise to have an ‘enforceable’ impact on banking IT infrastructure. The impending regulatory regime will be nothing but demanding and in that context the point can be made that existing banking infrastructure probably will not cope.
The average banking system today is a multi-layered composite of different eras – silos from product-centric days, medleys created by the M&As and the discrete bolt-ons of periodic modernization. Consolidating data from this archipelago of systems, processes and applications and presenting it in the unified, real-time format required by current regulations can have an adverse impact on the time and cost of compliance.
Note that a unified, real-time view is not merely an imperative for compliance. It is also a fundamental prerequisite for the customer-centric 360 degree model that almost every bank is attempting to build.
But creating a truly integrated enterprise architecture out of the existing patchwork of systems is a herculean task rife with operational hazards. Banks need a model that combines the truly transformative potential of rip & replace strategies with the peace of mind of phased rollouts.
The emergence of componentization as a motif in the banking solutions ecosystem might provide banks with the golden mean. The componentized approach allows banks to modernize in phases, and do so at a granular level.  It also enables the replacement of traditional silos with enterprise-level components that integrate systems, processes and data across LoBs and functions to create a unified view of the business. Banks can also design their component deployment strategies around their immediate business objectives, like the need to capitalize on emerging opportunities in specific customer, product or service segments. Most importantly, componentization minimizes disruption.
As long time perceptive users of technology, banks do not need a set of enforceable technology standards to ensure their IT systems are up to potential. What they need is a transformative model that delivers to pragmatic requirements of time, capital and continuity. Componentization has the versatility to tick all those boxes.
Read our previous blog in the “Simplified Banking” series

Related Blogs All Blogs


We practice Agile and Devops, but how do we measure and monitor Devops?
June 29, 2017


Value #Reimagined – Cloud for Cost efficiency to Cloud for Business Enablement
March 12, 2018

Leave a Reply

Your email address will not be published. Required fields are marked *