Export (0) Print
Expand All

Architecting Regulatory-Compliant Architectures

 

Mike Walker
Microsoft Corporation

January 2007
Revised March 2007

Applies to:
   Regulatory Compliance

Summary: This article will serve as a guide for architects who want to design banking solutions that are compliant with the latest regulatory laws. There is no one-to-one mapping or checklist to solve these issues. However, this article will provide some interesting insight into how these regulatory concerns can be addressed by using the latest Microsoft technologies. We will be using a business scenario coupled with many of the technology challenges in banking. The hope is to make a real-world example of the relevant issues in the banking landscape. (16 printed pages)

Contents

Introduction
How Does Architecture Help?
Architecture Overview
Mapping the Loan-Origination Architecture to Solve Compliance Issues
Addressing the Need
Conclusion
References

Introduction

In the past 10 years, there has been a strong regulatory impact on the financial-services industry. It has undergone significant changes with respect to legislative and regulatory compliance. Financial institutions (FIs) are faced with an increasing number of local, national, and international compliance requirements that have placed a heavy demand on formalized processes, IT governance, and information security. As a result, risk-management and auditing processes are critical, and newly formed practices and information are becoming more and more available to FIs.

This article will serve as a guide for architects who want to design banking solutions that are compliant with the latest regulatory laws. There is no one-to-one mapping or checklist to solve these issues. However, this article will provide some interesting insight into how these regulatory concerns can be addressed by using the latest Microsoft technologies. We will be using a business scenario coupled with many of the technology challenges in banking. The hope is to make a real-world example of the relevant issues in the banking landscape.

Within loan origination, there are many regulatory concerns. We will dive into a loan scenario to make this applicable to your business. In this scenario, we will show how meeting compliance requirements will improve efficiency and reduce costs when an organization can properly assess risks, as well as the risks associated with non-compliance.

Enabling Technologies

Described here are the enabling technologies that are used in our scenario:

  • BizTalk 2006—By using BizTalk, banks can now orchestrate their business processes in a dynamic and fluid way.
  • .NET Framework 3.0 (WPF, WCF, WF)
    • Windows Presentation Foundation (WPF) can reduce the training time of loan executives, officers, underwriters, and secondary marketing personnel. This is increasingly important in high-turnover areas.
    • Windows Communication Foundation (WCF) will reduce the increased complexities of the integration needs. For example, it will cover integration of broker, correspondent bank, flood, mortgage insurance (MI), appraisal, credit, verification of funds, and cross-sell services.
    • Windows Workflow Foundation (WF) provides banks with the flexibility to create workflows around documents such as Office Excel, Office Word, and Office PowerPoint.
  • Microsoft Office SharePoint Server 2007 (MOSS) for SharePoint, Excel Server, documents
    • Office SharePoint can host your loan documents in a centralized, versioned, and secure environment, while adding functionality, such as approval workflows and communications using Office Communicator 2005.
    • Office Excel Server can host your Office Excel data in a central store with robust relational-database features that will provide protection of data, centralized backup procedures, a single version of the truth, and security around sensitive data. This will provide the Office Excel user experience for multiple services without cross-training on other applications.
    • Document formats have been changed to Open XML, an open document format. This will ensure cross-platform compatibility, robust integration, document manipulation opportunities, and controlled data-integrity checks from within the documents themselves.
  • Microsoft SQL Server 2005—This is the repository of choice for storing all of the sensitive loan data that is needed for this solution. Additionally, SQL Reporting and Analytical Services will provide robust Web Parts to plug into our MOSS portal.

Banking Regulatory Challenges

To date, most financial institutions have addressed pieces and parts of some of the larger regulations. The issue that FIs are having is addressing all of these requirements across the enterprise in an efficient and productive way.

FIs are often frustrated by the lack of management tools and metrics. Furthermore, because of the fact that many solutions are purchased, applications, intellectual property (IP), and data are not necessarily owned by the FI. These are commonly known as Commercial Off-the-Shelf (COTS) technologies. FIs are struggling with how to enforce, develop, maintain, and measure compliance for these architectures.

This article will highlight potential solutions in the context of loan origination for certain aspects of the following regulations:

Regulation C & Z

BASEL II

HMDA

PCI

SOX

CRA

Truth and Lending

Anti-Predatory Lending

COBIT

EFA

How Does Architecture Help?

Holistic approaches are required to address these compliance issues. No longer can FIs just look at single-application architectures. The perspective has to change to comply effectively with regulations. This is a requirement to look across the enterprise when addressing regulatory issues. Enterprise Architects are focusing more on standardized IT frameworks and processes that can help drive these initiatives.

Bb233047.archrcarch01(en-us,MSDN.10).gif

Figure 1. Scope is key.

Similarly, in Enterprise Architecture, by looking at just one architectural view at a time, you can easily lose perspective on the impacts that single architecture has on the enterprise. For example, in Figure 1, we have a view of a city. If architects just evaluate an architecture (building) each time that it is being designed and deployed (built), without considering traffic, infrastructure, views or other impacts, we would have quite a mess on our hands. Without the role of the city planner, cities would not have effective roadways, traffic would be horrendous, and plumbing and electricity would not work or be as reliable as we have become accustomed to. The same is true in enterprises. They are living and breathing organisms with complex parts, and there is not a simple solution. However, by identifying the common requirements of multiple regulations, you can begin to develop a set of process views across your enterprise. This view can expose gaps that require remediation and can extend best practices across the enterprise.

IT Capabilities Needed to Be Successful

Instead of performing one-to-one mappings between IT capabilities and the specific regulatory laws, we will generalize the regulatory requirements. This eliminates many of the overlaps in the laws, making the task much more manageable. For example, Payment Card Industry (PCI) data-security standards have many of the same requirements around safeguarding data as the Financial Services privacy laws. The only difference is the application of that information and security mechanisms.

  • Confidentiality—Confidential, personal, and sensitive information cannot be exposed to unauthorized organizations or individuals.
  • Integrity—Data cannot be modified by unauthorized organizations or individuals, and the completeness and accuracy must be ensured.
  • Availability—Information must be available to the right people at the right time, to support timely and accurate financial reporting and to fulfill demands for information by regulators, investigators, and court subpoenas.

Organizations must implement policies and procedures to make sure that individual and departmental activities conform to compliance requirements. However, merely publishing policies and procedures—or buying technologies to ensure confidentiality, integrity, and availability—falls short of compliance. An organization must exercise due diligence in enforcing the execution of those policies and procedures.

  • Procedural rigor—An organization risks becoming quickly bogged down if executives and managers must manually enforce procedural rigor, and if workers must perform with busy-work mandated by a bureaucracy created out of compliance requirements. Good workflow automation enforces compliance and performance of business processes and policies as unobtrusively and automatically as possible.

To support audits and investigations, an organization must also be able to prove that it performed compliance procedures when needed, that its technology controls were active, and that they performed throughout the period in question. This requirement creates a documentation burden on top of other work that is associated with compliance policies. This documentation burden creates a need for IT involvement.

  • Auditing and logging—Auditing and logging trace how individuals access and use resources, and how they execute business procedures. Systems that process sensitive data must securely log, maintain, and provide critical event information to ensure a clear audit trail.

Audit trails and logging are especially important for two of the pillars of information security: scope and integrity. First, audit trails are crucial in determining the scope of disclosures of confidential information. Being able to reconstruct who accessed what information and when allows an organization to inform just the people whose information was compromised—sometimes greatly reducing the fines and other costs that are in direct proportion to the quantity of individuals whose information was compromised. Second, logging facilitates integrity controls. Technology might not always be able to prevent an authorized user from maliciously or inadvertently modifying information, but an audit trail provides a control and allows the organization to understand the impact of the incident. For example, it is not enough to point to a written policy that governs how financial spreadsheets and their formulas are maintained. Compliance and audit professionals want to see an audit trail of changes to such spreadsheets that shows who accessed them, what was modified, and when.

The following table describes the products in the 2007 release that are relevant to regulatory compliance.

  Feature-to-Compliance Mapping
ProductDescriptionFeatureConfidentialityIntegrityAvailabilityProcedural rigorAuditing and logging
Microsoft Office SharePoint Server 2007Office SharePoint Server 2007 enables development of intelligent portals that seamlessly connect users, teams, and knowledge. Such portals can help people take advantage of relevant information across business processes and work more efficiently. An important feature is the business data catalog (BDC), which indexes data from external systems and databases, such as CRM systems, so that it can be searched by the portal search feature.Web content management (WCM)  XX 
  Enterprise search  X  
  Document and records managementXXXXX
  Auditing and loggingXX XX
  Records centerXXXXX
  Information-rights management (IRM)XX   
  Document policiesXX X 
  Extensible hold and content expiration infrastructure  XX 
  Role-based targeting and securityXX X 
Microsoft Office SharePoint Designer 2007Office SharePoint Designer 2007 provides you with tools to create and deploy interactive solutions based on SharePoint Products and Technologies, without having to write code.

You can automate business processes, such as document approval, custom event notification, and other collaboration tasks, by using the Workflow Designer feature.

Custom workflows  XX 
  Custom notifications  XX 
  Custom tasks   X 
  Data aggregation and reporting  X  
Microsoft Windows SharePoint ServicesWindows SharePoint Services allows teams to create Web sites for information sharing and document collaboration, benefits that help increase individual and team productivity. By supporting such IT resources as portals, team workspaces, e-mail messaging, and presence awareness, Windows SharePoint Services enables users to locate distributed information quickly and efficiently, and to connect to and work with others more productively.Workflow processes XXX 
  E-mail messages and alerts  XX 
  Content typesXXXX 
  Search  X X
  Versioning and history X X 
  Document metadataXXXX 
  List-level and item-level securityXX  X
Microsoft Office Communicator 2007, Microsoft Office Communications Server 2007Office Communicator 2007 is an integrated communications client that relies on Office Communications Server 2007 to help teams and information workers communicate in real time more easily and effectively. Office Communicator 2007 integrates with Microsoft Office system applications and secure enterprise telephony infrastructure. Information workers can see the presence status of other team members at all times; for example, they can see whether someone is online and whether they are in the portal.Instant Messaging (IM) session history  X X
  Encrypted messagingX    
  Secure communicationsX    
Microsoft Exchange Server 2007Exchange Server 2007 enables knowledge workers to gain access to critical business communications almost whenever and wherever they need to, and is designed to deliver greater security, availability, and reliability.Secure e-mail message repository  X X
  Permission controlXXXX 
  Message classification  X X
  Transport rulesX  X 
  Secure communicationsX    
Microsoft Office Outlook 2007Office Outlook 2007 provides an integrated solution for managing your time and information, connecting across boundaries, and remaining in control of the information that reaches you.Classified e-mailX    
  Information-rights management (IRM)XX   
  E-mail records management  X X
  E-mail search  X X
  Secure communicationsX    
Microsoft Office Excel ServicesOffice Excel Services, a feature of Office SharePoint Server 2007, supports loading, calculating, and displaying Office Excel spreadsheets in a Web browser. Users can publish spreadsheets and view them with any modern browser, without installing any software on the local client computer. This capability allows organizations to share spreadsheets without exposing sensitive business information.Spreadsheet integrity X   
  Spreadsheet archiving and centralization  X X
  Role-based views and access controlXX   
  Data securityX    
Microsoft Office Project 2007Office Project 2007 helps project managers, business managers, and planners manage schedules and resources. Office Project 2007 helps you set up projects quickly with templates, communicate project data, and track and analyze project status.Sarbanes-Oxley (SOX) templates X X 
  ISO 9001 templates   X 
  Finance and accounting templates   X 
  Feedback monitoring   X 
  Report preparation X   
Microsoft Office Forms Server 2007Office Forms Server 2007 provides scalable, standards-based electronic forms solutions with enhanced security that can help your organization extend the reach of forms-driven business processes to anyone with a Web browser.Forms archiving and centralization  XX 
  Data validation X   
Microsoft Visual Studio 2005 Tools for the Microsoft Office SystemVisual Studio 2005 Tools for the Microsoft Office System is a professional development environment for individual developers building line-of-business (LOB) applications using the Microsoft Office System. These tools enable developers more easily to extend solutions using managed controls, and provide a more intuitive design, development, and debugging experience.Custom development and extensibility   XX

Architecture Overview

The following figure shows the communication channels between the various products in the 2007 Microsoft Office System.

Click here for larger image

Figure 2. Communication channels between various products in 2007 Microsoft Office System (Click on the picture for a larger image)

Mapping the Loan-Origination Architecture to Solve Compliance Issues

In the loan-origination business, there are many business drivers for banks: process consolidation, regulatory compliance, and faster product delivery (loan completion). Loan products change frequently and are usually dynamic, based on location (regional or state). Developing and modifying products in an agile manner enables banks to be highly competitive and adaptable in key markets. Also, compiling and staying on top of regulatory laws is always a challenge, given the turbulent changes happening in the industry today. Laws such as Community Reinvestment Act (CRA), Home Mortgage Disclosure Act (HMDA), and Anti-Predatory lending often require cumbersome integration issues and data-mining exercises. The complexities of multiple processes for regions, tiered pricing, or special market demands complicate the overall process. Banks are now trying to consolidate processes to reduce this complexity and maximize value. Not only are banks trying to reduce the amount of processes, but they are trying to reduce what is called the "application-to-delivery cycle." By reducing this window, banks are seeing savings in the range of three basis points and closing more loans per month.

Now that we understand the business architecture, we will describe the technical architecture in each logical tier of the solution. This is shown in Figure 3.

  • Presentation layer—Serves as the user interface. ASP.NET 3.0 Web forms are hosted on the Windows SharePoint Portal Server. SharePoint will provide the underpinnings for the application. There will be several services that can be inherited from this environment—specifically, the portal architecture that will be required to deploy Web Parts for this solution.
  • Application Services layer—A reusable layer in the architecture. This will allow applications to use functionality such as Digital Rights Management, Document Libraries, Workflow, and so forth.
  • Services layer—Provides an infrastructure to communicate messages. The MOSS layer will use Windows Communication Foundation. The Integration layer will use BizTalk.
  • Business Rules layer—Centralized business rules to build consistency, reliability, efficiency, and cost reduction of system architectures. BizTalk has a built-in BRE that we will use.
  • Orchestration layer—Process development and management occurs in this layer. BizTalk also has a robust orchestration engine for BAM types of activities. Extensible BPEL is used throughout to ensure interoperability between other orchestration systems.
  • Data Services layer—Relational-database services and management occur in this layer.

Bb233047.archrcarch03(en-us,MSDN.10).gif

Figure 3. Logical architecture

There are many layers to this architecture. One might think that it is overly complex. However, it is really quite simple, compared to how processing is done today. The same system would be multiple systems dollied together using complex point-to-point integrations, with even more complex and fragile monitoring systems.

Addressing the Need

Now that we have defined the business and the corresponding architecture, we will dive into how we address the regulatory needs in our architecture. This section will highlight some key areas in which many FIs have compliance issues. The goal is to give the architect a different perspective on the architecture.

Data Integrity and One Version of the Truth

Data at rest is an increasing concern for enterprises—especially within financial services, where there has been so much fraud and privacy-violation concerns. The term "data at rest" refers to having information physically in a particular location. We find that data is all over enterprises. For example, information as simple as an Office Excel document on your PC laptop can introduce concern.

Just because information is not in the form of data housed within a database does not mean that it should not be managed. The proliferation of Office Word and Office Excel documents causes many issues in the data-management world. Take a real-world scenario: You are tracking your current loan pipeline in an Office Excel file for management and reporting purposes. Later that evening, you stop by your local grocery store and leave your laptop in the back seat of your car. Thirty minutes later, you find a pile of broken glass and a missing laptop. For you, this means having to go through a little bit of a hassle to file claims and ingratiate yourself to your boss. However, for your banking establishment, this is a substantial loss. Not only are they out $2,000, but there is a steeper penalty associated.

If this happened in the U.S., this means that the FI must now send out press releases, letters to customers, and (potentially) fines. That bill for $2,000 does not seem so high now, with the thousands—if not millions—of dollars lost to the printing of letters, countless hours of analysis and data mining, and—most importantly—reestablishing customer confidence. The cost to customers is substantial, too. They can spend years dealing with identity-theft issues, as well as debates with credit-card companies and banks.

The loan-origination architecture addresses the following concerns:

  • Data is sensitive.
  • Version data.
  • Audit data.
  • Control unauthorized data sharing.

Bb233047.archrcarch04(en-us,MSDN.10).gif

Figure 4. Example of using Office Excel as a client

To address these concerns, we will centralize information as much as possible. There inevitably is data from other LOB applications. In those cases, the loan-origination reference architecture will provide a platform in which organizations can consolidate their LOB data and applications. There will be cases, however, in which it is not ideal to consolidate. For those cases, this reference architecture will provide the integration hooks to get and receive data through standardized XML. We will use industry-standard Mortgage Industry Standards Maintenance Organization (MISMO) XML messages, because this information spans across the enterprise in varying formats.

Jumping into our scenario, there are quite a few areas in which we centralize data. One of these is the centralization of product and rate data. In many loan areas, the process of generating rates is done through Office Excel. After rates are entered and calculations applied, these rate sheets are then distributed.

Bb233047.archrcarch05(en-us,MSDN.10).gif

Figure 5. Calculating and distributing rates

As shown in Figure 5, Office Excel rate sheets are stored in a centralized document library. From here, we can do a host of different things with the document. For example, we can add version control (which we will talk more about, later in this article).

Using Workflow for Separation of Duties

Separation of duties is needed in many areas of an organization. We will focus on the business-process aspect, instead of the IT aspects. Often, the business side is overlooked. We will show you how this reference architecture addresses those concerns.

As defined in Figure 5, we are centralizing the product and loan data. We will then use workflow that will wrap the document, allowing for defined assignments to resources and—ultimately—our approval processes for verifying the validity of rates. Additionally, we will use the WF to provision our rate information to many sources, including: internal LOB systems, our SQL Server database, brokers, and underwriters. This will automate manual tasks that introduce errors that often happen when data is re-keyed into other systems.

Bb233047.archrcarch06(en-us,MSDN.10).gif

Figure 6. Rate process

Steps:

  1. Rates sheet templates—Through the use of standardized rate templates, rates can be developed in standardized ways. Calculations can be stored on the server to ensure that the right calculations and versions are used.
  2. Rates are uploaded—Through Office Excel, the rates are saved onto a secure Rate Management document library.
  3. Approval workflows started—The workflow is automatically kicked off, as soon as the file is saved on the Rate Management document library. Alerts are sent to the necessary personnel to review the rates.
  4. Approvals granted—The rates are validated and approved.
  5. Alerts sent—Workflow begins by alerting all necessary personnel.
  6. Underwriters view data—Rates can now be consumed in various ways. Underwriters may choose to use the client tools to access this data.
  7. Brokers view rate data—Data is available through a standard Office Excel Web Part.

Click here for larger image

Figure 7. Demonstration of the Approval process workflow capabilities (Click on the picture for a larger image)

Not only does workflow address separation of duties, but we will also address many other aspects, too:

  • At each step through this process, the user is being audited and the credentials are validated against the identity store. This ensures that the right users have access to perform the necessary tasks and avoids any confidentiality issues.
  • Automated processes also eliminate users from having access to data.
  • Centralized management of data through the use of document libraries.
  • Full auditability of the process.
  • Business-Process Management (BPM) metrics can be applied, to delve into the health of the process.

Loan-Document Retention

There are strict rules around retaining records in the loan business. MOSS document libraries provide us with these records-management capabilities, as shown in Figure 8. Loan documents are stored as standardized MISMO XML files. MISMO is the mortgage XML payload standard for representing consumer mortgage data.

The MISMO XML files work within a workflow. The Master Loan Workflow (MLW), which is hosted within Windows Workflow Foundation (WF), provides the process-management layer, while the MOSS document library provides all of the versioning and retention capabilities.

Bb233047.archrcarch08(en-us,MSDN.10).gif

Figure 7. Solving regulatory issues with MOSS technologies

The records repository has several features that help ensure the integrity of files that are stored there. First is the ability to ensure that records are never automatically modified by the system. This means that records that are uploaded to a records repository and then downloaded later will be identical, byte-for-byte. Secondly, there are the default version and the audit settings that monitor changes to content, to prevent direct tampering with records. Thirdly, records managers can add and maintain metadata on items separately from the records' metadata. This allows information such as who manages the item to be changed without modifying the underlying record. Changes to this metadata are versioned, too.

Click here for larger image

Figure 8. Auditing loan documents (Click on the picture for a larger image)

The audit policies can be configured to record user actions automatically that affect the life cycle of a document, as shown in Figure 8. Documents are audited when they are viewed, edited, versioned, published, and removed. LOB applications can use these features, too. By using the MLW, we can also add relevant entries to the audit log, such as when an approval workflow is completed.

Information-Rights Management Protection (IRM)

When protecting information, there are several areas in which we could look; however, we will focus on the distribution of information by way of e-mail. E-mail internally and externally is sent more often than we notice. Current studies have identified that approximately 70 percent of information workers spend a fifth of their time or more on e-mail–related tasks.

That is especially true in loan origination—particularly, between the brokers and the lender's loan-processor department. As far as compliance issues, these e-mails must follow the same rules that any other document would have. If there is sensitive information, they must be secured and have limited access. The same is true with personnel within the lender's institution: Sensitive customer information must be secured.

Bb233047.archrcarch10(en-us,MSDN.10).gif

Figure 9. Architecture behind accessing secure documents with IRM

Within our loan-origination architecture, we will employee the IRM controls within Microsoft Exchange and MOSS, to ensure the confidentiality of the data that is sent. We not only control who receives the information, but we also ensure that the data can be seen only by the receiver. The information cannot be copied, nor can screen shots of the desktop be captured. This is all controlled by the underlining IRM controls.

We are not limited to just e-mail messages. These same types of IRM protections can be extended to traditional .NET applications, smart clients, or existing LOB applications. This, in turn, uses one centralized infrastructure platform. By using this centralized application-services layer, centralized IRM reduces the exposure of information security.

Conclusion

We only focused on a fraction of the regulatory concerns. We have laid the foundation, with some concrete examples with the loan-origination reference architecture. Architects can look at real-world examples and apply this architecture to their solutions.

The exposed features in the loan-origination reference architecture that uses MOSS 2007 and Microsoft Exchange shows how to address these regulatory concerns without complex coding. This approach will allow financial organizations to worry less about the programming and infrastructure issues, and instead to focus on the laws and how it affects their business.

References

Microsoft Office Communicator 2007

MSDN Financial Services Industry Center

Compliance Features in the 2007 Microsoft Office System

Planning Records Management

Office Business Applications Center

Show:
© 2014 Microsoft