Outcomes-focused regulatory supervision is designed to give flexibility to the regulated by avoiding unnecessary prescriptive rules on process, but giving clear guidance on what it is that companies must achieve.

The supervision is designed to help companies achieve the right outcomes , encourage companies to be open in their dealings with the supervisor and abide with the spirit of the regulation.

Controlling a business process according to rules has meant enforcement of controls that lead to over laborious work and difficulties in implementation and embedding the risk management.

This has not proven to be sustainable either in building a working relationship between regulated and the supervisor or in managing ongoing compliance.

Financial regulation in the UK is principles based and the supervision requires evidence of the principle rather than compliance to a checklist.

Key areas for evidence are:

• Senior management buy-in and commitment to policy objective
• Strength of Management Information (MI)
• Process control and consistency
• User education. 

The supervisors are looking for cultural buy-in and, in exchange, offer flexibility over the manner of compliance, expecting this to be supported by an education programme and enhanced MI from companies to support the risk assessment. The regulator, in this scenario, also has a greater focus on providing guidance related to the outcomes companies are expected to achieve, rather than the "how" of compliance with individual rules.

Regulation like the UK Corporate Governance code, the Companies Act 2006, will be looking for a new code of practice to be integrated into firm culture, rather than for companies to have another set of tick-boxes added to their forms.  Solvency II, the Retail Distribution Review are principles based legislation supervised in this way and it is an approach currently favoured by legislators responding to criticism from the regulated.

This is also the case for the USA Sarbanes-Oxley (SOX) regulation. For example,  and from the ICT and information security perspective, tick box compliance has, for SOX, meant implementing CobIT via the interpretation of an external auditor and with results that sometimes don't seem relevant.  SOX  is supervised differently today (mid 2010) than during, say, 2004 when the focus was on "how to comply", and less on outcomes. Sox 2010 allows for more individual risk assessments - with a set of core requirements that should result in outcomes that describe what compliance with the core duties/principles is achieving.

A key requirement then is the need for companies to develop, collect and analyse relevant MI measures. Rather than these solely feeding into compliance reporting, companies need to show that MI is both relevant to supporting the delivery of compliance objectives,  as well as feeding into management decision-making and employee performance evaluation. This requires a strong analytical focus on use of MI (rather than just reporting). Furthermore, companies must demonstrate ongoing improvement of MI itself and in attendant business processes and policies, in order to remediate and continually improve.

From a system perspective, this is dashboard type compliance reporting, where management views the top-level performance measures and drills down into the underlying data and qualitative contextual information to understand performance issues. This, along with the need for ongoing improvement, means the development of an information and performance management system layer designed to provide the flexibility that can cope with future regulatory change  and reporting requirements.

These are summarised as:

• KPI and other MI measures will be subject to change over time; this means that it is no longer optimal to use highly defined or hard-coded applications for the automation of data collection and reporting. Systems need to deal with evolving measure requirements, with the ability to easily work with new measures or change existing ones. On the data collection side, firms need to consider all documentation and customer interaction as a source of potential MI for compliance, and approach document and record management accordingly (e.g. ensure records management captures all documents and electronic forms).
• There has to be a high level of data depth; this will allow senior management to drill-down into potential areas of interest/concern and to have a more dynamic interaction with the data. This also has implications for data collection and storage, requiring a centralised approach; underlying data and analysis should not reside offline, ensnared in spreadsheets or on paper.
• There is a need for stronger focus on analytics than report generation;  firms need to be able to understand data trends and identify patterns in data to ensure objectives are being delivered and improvements are being made. As with measures themselves, the need will be for generic analytical capabilities rather than defined analysis, as analytical requirements will evolve over time. Compliance applications will need to be able to take a business intelligence platform approach, rather than specific analytics, with subsequent need for additional development for new measures or approaches
• Ideally, compliance MI should be closely integrated with core business performance MI so that relevant measures are included as part of the relevant business function's local operational metrics.

These outcomes based regulatory compliance requirements support Information Architecture  and Service Orientated Architecture (SOA) objectives;  the result being an information-driven SOA.

SOA helps identify where enterprise information is produced or consumed - and a formal SOA process will uncover policies and business rules, that identify stewardship and data quality needs.

Information Architecture addresses the common compliance related challenges .

1. Information overload; Too much information, and too little that is relevant. Most people cannot find the information they need in a timely fashion.
2. Multiple versions of critical master data are replicated among ERP, CRM, legacy systems and analytic systems, it is difficult to consolidate, reuse or federate information.
3. Lack of focus on data quality in systems which can often result in loss.
4. There is a disconnect in the composition and abstraction process when no consistent information architecture is in place.

• A design for the structuring and managing of all types of information would be an enterprise information architecture (EIA).

SOA requires developers and business analysts to know where to find and how to use various information sources. The move from tightly coupled to loosely coupled systems means knowing the location, format, structure, context and usage of information is imperative.

Outcomes based compliance requires multiple information sources (inside and outside the organization),  usually with different formats, protocols and vocabularies, from diverse information producers and consumers.  EIA supports the development of relevant and available information through a set of requirements, principles and models that enable the organization to flexibly share and exchange information assets. 

Outcomes based compliance is intensifying the need to migrate from legacy data structures to agile data services and information sources that support the improvement of a business process; just building a corporate data model using relational techniques, has  along with the absence of structured processes for information sharing often resulted in the situation of multiple and conflicting information sources maintained in a web of point-to-point interfaces; which are difficult and costly to change and horrible for compliance.

EIA goes beyond relational modelling to support a number of design and integration protocols.  It addresses "data at rest" and "data in motion" (for event processing), integrating structured information (such as databases) with less structured sources (such as documents).  EIA maintains its scope by focusing only on information assets critical to the business strategy defining common methods for sending and exchanging enterprise information via integration styles and, for compliance purposes, using a risk impact study.

There are three components of an information architecture:

1. First is scoping the boundaries of enterprise information and focuses on representations of content (structured and unstructured) that are significant  as determined by their impact.
2. Second is the identification of the uniform and consistent standards and guidelines within the EIA which enable the organisation to consistently share and exchange enterprise information - master data, metadata and integration patterns.
3. Third is the implementation of a program to implement Enterprise Information Management (EIM). EIM is the planning and design stage of EIA and continues through the development, deployment and optimisation of solutions. Organizations use EIM as a structured program management approach for implementing their EIA.

Each viewpoint within enterprise architecture includes three levels of abstraction which support the collaboration between EA and the rest of the organization. The levels of abstraction are:

• The conceptual, logical and implementation levels.

These levels support information management by guiding a variety of disciplines involved in the architecture, design, implementation and management of enterprise information.

1. The conceptual level is the sphere of abstract intent and goals. Deliverables include the high-level enterprise information model (defining what is enterprise information) and which identifies key information producers and consumers, and stewardship accountabilities for information producers.
2. The logical level deals with ideas, methods and techniques that can be applied as strategies to accomplish the conceptual goals. It focuses on how to approach a problem and what is required to get the desired result. Here, this includes common integration patterns and styles, master data models, vocabularies and ontology’s and metadata management services, such as meta models to link multiple sources across the diversity of sources.
3. The implementation level is the solution architecture. It represents the materials and resources that are developed to carry out the conceptual and logical design. Here, this includes information services (data integration and data quality), master data stores and database and software solutions.

The focus of EIA is on integrating, sharing and reconciling enterprise information assets. To do so requires three capabilities:

1.  Enabling the "transport" of information; Transport focuses on information services such as the common integration patterns or styles for moving data reliably and securely between information producers and consumers. Included here are data quality and data cleansing services to harmonize and rationalize disparate data into consistent and uniform formats. Additionally, these services must ensure that proper retention or archival policies are followed.
2. Enabling the "trust" and reliability of information; Master data management should ensure the trustworthiness of enterprise information critical across multiple business processes.
3.  Enabling the location and discovery of enterprise information; Metadata management services support the diverse communities of producers and consumers of enterprise information by enabling the discovery and location of enterprise information assets.

Data integration is a basic method of transporting information between producers and consumers. Common methods include ETL, data federations (views) and change data capture. However, transport doesn't stop there. Data quality profiling and cleansing are necessary to ensure that enterprise information is fit for purpose and harmonized based on simple standards of accuracy and integrity. The goal is to establish clarity across the diversity of enterprise information assets.

Composite applications represent the most closely knit and hardest to implement integration pattern. A composite application appears to the user to be a single application, but a look within the composite application will identify business logic or data that is a part of other applications. A composite application may service a client (for example, using a  web application that invokes transactions or calls to mainframe (Unix or Windows) applications and is transparent to the end user). Also, mashups bring together federated information (typically to support portal applications).

A key aspect of enterprise information architecture is definition of core subject areas. At the core of each business are fundamental subject areas. Examples are parties (customers, prospects, people, citizens, employees, vendors, suppliers and trading partners), places (locations, offices, regional alignments and geographic locations) and things (accounts, assets, policies, products and services). Subject area models include organisational hierarchies, sales territories, product categories, pricing lists, customer segmentations and preferred suppliers. These models also define the standards and uniform vocabularies that are used to achieve consistency and information sharing across the enterprise. Different industries have different characteristics when it comes to master data. Service industries, such as financial services and government, are focused on the customer or citizen entity. Product-centric industries, such as manufacturing and retail, see product information management as the highest priority.

Managing metadata and reconciling semantics is a key requirement for managing the diversity of information assets. Metadata is spread throughout the organization in unmanaged file folders, disparate databases, spreadsheets, local desktops and even drawers. Metadata supports the discovery, reuse and shareability of enterprise information. Metadata lets you find what you need fast such as the definition of a term, the schedule of a production job, the name of a person to call if you have a question, a logical data model to map against new business requirements. Metadata leverages information assets. Leveragability is reusing what you have - adopting the standards of key terms, storing documentation in a common place.  Semantics is that part of metadata management that enables components to flow seamlessly during information exchange.

Information producers and information consumers need to:

1. Find authoritative information sources (master data stores);
2. Know the underlying location, structure, context, quality and usage of enterprise information;
3. Determine how to resolve differences in meaning (semantics);
4. Understand how to profile and ensure data quality; and
5. Apply methods to connect to data sources (choosing among several data integration technologies) for service composition.  Metadata is typically managed through metadata repositories (centralized catalogues of metadata) and metadata registries (federated metadata sources).  Organizing metadata requires a schema known as a meta model.

• Companies are developing meta models to structure and manage their metadata.

A Data Reference Model (DRM) will promote the common identification, use and sharing of data/information to optimise a data architecture for information integration, interoperability, discovery and sharing, and provides a standard means to describe, categorize and share information. There are three standard areas to consider:

1) Data Description; includes data models and data assets.

2) Data Sharing; includes data exchange packages and query points.

3) Data Context; includes controlled vocabularies and enterprise architecture alignment - and the management mechanisms for capturing the context of data in organizations. The DRM is implemented using different combinations of technical standards and information exchange patterns. Examples of information exchange patterns are the different dialects of XML (such as XBRL) - inter-application messaging infrastructure will likely formatted in XML. Taken as a whole, the DRM can be used to assess the current state of your information architecture and to chart a road map to an improved information architecture.

Meta models such as a DRM can organize, share and exchange all types of content and is designed to answer the challenges of outcomes based compliance reporting.

An example of outcome based supervision is the FSA's Treating Customers Fairly (TCF) initiative. The TCF regulation is intended to protect retail customers and increase the transparency of fees and charges along with more clarity of communication around products and services with risks plainly and consistently laid out.  The FSA is not content with a checklist approach to compliance, (e.g. one based around ensuring suitability or complaints management). Companies need to demonstrate a cultural buy-in towards meeting objectives and control of processes in order to be actively ensuring TCF outcomes are achieved.

The TCF initiative provides a good guide for the priorities UK supervision  is likely to adopt for the rest of its beefed up compliance programs. One of the key aspects the FSA were  looking for in the roll-out of the TCF initiative is evidence that senior management had accepted, and bought into, the goal of delivering fair treatment to customers and that this has been instilled into each firm's culture. This entails all staff understanding what fair treatment of customer means and knowing that this is expected at all times. When errors do occur, these are expected to be dealt with promptly, put right, and the relevant processes/policies adapted to prevent repeat occurrence.

The TCF initiative showed that the FSA is not prescriptive as to what MI is used; rather, the onus is on the regulated institution to collect all relevant MI, (e.g. key performance indicators (KPIs), survey data, sales monitoring or checklists), and to ensure both that these are acted upon and that they deliver the required outcomes.