E-Sign Transactions Platform: The Enterprise Architecture to Implement Electronic Transactions Requiring Electronic Signatures White Paper

Transcription

1 E-Sign Transactions Platform: The Enterprise Architecture to Implement Electronic Transactions Requiring Electronic Signatures White Paper

2 INTRODUCTION More than ever enterprises want to completely automate their business processes. The challenge of digitizing paper-based signature processes is the final obstacle in their quest for a paperless real-time enterprise. As the legal and cultural barriers crumble, enterprises are warming up to the concept of legally binding electronic signatures. Primarily, enterprises have identified e-signatures as a mechanism to eliminate the inefficiencies and expense of paper-based transactions. Enterprise IT staff members are beginning to address the technical challenges needed to complete business process automation. This white paper will aid enterprise architects and business managers in understanding the requirements and the optimal architectural approach to bridge the gap to complete the automation of business processes. We will: 1. Outline a framework that identifies the security, legal, and automation requirements for the E-Sign Transactions Platform. 2. Compare two feasible architectural approaches. 3. Recommend the enterprise architecture to implement electronic transactions requiring electronic signatures. EXECUTIVE SUMMARY Enterprises are faced with the challenge of automating business processes that require digitization of paper-based signature processes. As enterprises continue the migration of higher risk paper-based transactions to the digital world, they are faced with four key questions: 1. How do they ensure that transactions have end-to-end security? 2. Are transactions in the digital world legally enforceable in the court of law? 3. Are signed electronic transactions capable of being intelligently processed by business applications? 4. Will end users accept the transition to electronic signatures? There are two feasible architectures to implement digitization of paper-based signature processes: A document-centric architecture and transaction-centric architecture. The document-centric architecture takes manual processes and moves them to the digital world rather than engineering the processes for further efficiency. This approach is tied very closely to the presentation application and is better suited for content publishing than application processing. In contrast, the transaction-centric architecture enables efficient and effective content processing by understanding data semantics. This aspect of the architecture enables enforcement of sophisticated enterprise policies without disrupting existing business applications. This approach implements a single framework that supports multiple presentation formats. When comparing these two architectural approaches the following observations can be made: The transaction centric architecture enhances the existing IT infrastructure by adding electronic signature capabilities to enable enforceable trusted transactions. The document-centric approach allows departments to build one-off solutions that are application-specific and that cannot be leveraged by enterprise business applications. As the document centric approach mimics the paper processes it is easy to implement a proof-of-concept. Business transactions that require authorization by their very nature are dynamic and require multiple interactions before the transaction is processed. The transaction-centric architecture supports data field level security, privacy and routing rules enforcement, reducing the business risk of migrating to an electronic medium. The document-centric architecture is well suited for one-way communication where content needs to be published and trusted by recipients. The transaction centric architecture allows signed data and its presentation to be cryptographically linked together. This ensures data integrity and enables trusted data exchange between enterprises. On the other hand, the document centric architecture will force enterprises to adopt a proprietary/application specific presentation and data format. The transaction centric architecture becomes part of the IT infrastructure, which allows enterprises to enforce their security, compliance and privacy policies independent of individual business applications. The document centric architecture will require investments in business applications to support these requirements. Conclusion The transaction centric architecture is a flexible architecture that scales from departmental E-Sign Transactions Platform Page 2

3 solutions to enterprise implementations while satisfying the security, compliance, and intelligence needs of different transaction categories. The document centric architecture is not scalable for enterprise solutions and is appropriate only for departmental systems implementing a point solution. BACKGROUND Benefits of Going Digital When Johann Gutenberg invented the printing press in 1436 he sparked a communications revolution. That revolution is still going through a transition unlike any that humans have ever experienced, and with far-reaching consequences. With the advent of the Internet the same revolution has made communication faster, cheaper, and more accessible. Enterprises continue to find ways to move paperbased processes to the digital world in order to take advantage of the inherent benefits. Paper is still the most abundant office supply in today's enterprises. Despite an unwavering resolve to migrate business transactions to the digital world, organizations have had limited success. In order for enterprises to remain competitive in the 21st century, real-time business is paramount. There are well-known benefits of going digital, which include: Increased customer convenience Process Optimization Better security Compliance with regulatory mandates Migration from the paper world allows integration with current electronic processes. The ability to move processes online allows organizations to perform business in real-time while ensuring that information flows are timely, accurate, secure, and validated. According to IDC, a company of 1000 people spends about 81,700 person hours each year moving paper documents, including 1 million faxes, 9 million pages printed, and 4 million pages copied. Enterprises clearly understand the benefits of enabling paperless transactions. However, there are cultural and legal barriers, along with technical challenges that need to be addressed before a solution is deployed. Enterprises require solutions that mitigate business risk while being cost effective. Enterprises typically classify business transactions based on business risk and processing complexity to identify cost effective solutions. For example, it is not cost effective to require the highest-level security solution for a low risk business transaction. A Framework to Define Enterprise Needs We will establish a framework that classifies business transactions. This will help us identify the features of a cost effective solution. More importantly, we will outline the different security, compliance and intelligence requirements of the solution needed to mitigate business risk. Enterprises are beginning to reap the benefits of migrating lower risk paperbased transactions. Figure 1 Summary of Transaction Classes CLASS SECURITY COMPLIANCE INTELLIGENCE Class I No Risk Authentication: None Authorization: None Confidentiality: None Signature: None Audit: None Integrity: None Integration: None Workflow: None Portablility: None Class II Low Risk Authentication: Weak Authorization: Weak Confidentiality: Data in Transit Signature: Click-thru Audit: Jounral Integrity: None Integration: None Workflow: None Portablility: None Class III Medium Risk Authentication: Strong Authorization: Strong Confidentiality: Data at Rest Signature: Ceremony Audit: Jounral Integrity: Weak Integration: Needed Workflow: Needed Portablility: None Class IV High Risk Authentication: Extremely Stong Authorization: Strong Confidentiality: Data Element Level Signature: Ceremony Audit: Tamper Proof Integrity: Guaranteed Integration: Needed Workflow: Needed Portablility: Needed E-Sign Transactions Platform Page 3

4 Unfortunately, enterprises are having limited success when they attempt to migrate higher risk transactions to the digital world. This framework enables organizations to map out an enterprise solution, while meeting today's departmental needs. The following are the four classes of transactions (Figure 1): Class I Transactions Class I transactions are those that have no risk and are low in complexity. Examples of these transactions include downloading of white papers or product fact sheets from an organization's web site. Another example is Government agencies disseminating information on the web such as current regulations. Enterprises typically collect information from people to provide access to these documents. This data is used to trigger a follow-up action rather than to verify authorization. Data that is collected cannot be authenticated. These types of transactions do not require any authentication, and thus cannot support any authorization or confidentiality policy. In addition, these types of transactions usually do not require compliance or intelligence attributes that must be considered. Enterprises are quick to migrate Class I paper-based transactions to the digital world because they represent an opportunity to collect information from potential customers. Class II Transactions Class II transactions are low risk transactions. These transactions require authentication and are typically based on user-id and password or Personnel Identification Number (PIN). In addition, these types of transactions protect (encrypt) data transmission. They require some type of acknowledgement such as a clicking on an I Agree button. These are called click-thru signatures. Enterprises maintain an audit journal of record of these types of transactions. Integration with backend systems is a nice to have for Class II transactions. Software licensing agreements are a good example of Class II transactions, and the click-thru signifies acceptance of the terms. Other Class II transactions include on-line banking systems that allow you to look at your statements and even do your bill payments are another example of Class II transactions. Class III Transactions Class III transactions such as purchase order approvals or regulatory filings require stronger authentication and authorization as well as confidentiality of data in databases. For example, enterprises typically enforce financial spending limits due to an organizational hierarchy that mandates multiple levels of approvals. These transactions follow a prescribed authorization process where people understand the intent of their actions implicitly or explicitly. The electronic counterpart of this transaction has to ensure that the intent of the Figure 2 An Example of Types of Authenticication Biometrics with PKI COMPLEXITY PKI/Digital Signature PIN/Password None CLASS I CLASS II CLASS III CLASS IV Regulatory Guidlines Account Summary Regulatory Filing Wire Transfer RISK EXAMPLES OF TRANSACTIONS E-Sign Transactions Platform Page 4

5 action is clear before a commitment of an action. To avoid accidental actions the signing action will require input from the user beyond a mere 'clickthru'. In addition, enterprises will need to maintain a journal or record of all the transactions that are executed. There is need to support multiple signatures in a defined process environment. In general, these transactions will need to be integrated into back-end enterprise resource planning or financial planning and control systems. Class IV Transactions Class IV transactions have the most stringent requirements for security, compliance, and intelligence. Enterprises have the greatest difficulty in migrating these transactions to the digital world due to their inherent risk. Wire transfers or the redemption of funds from an existing account are good examples of Class IV transactions. Today these business transactions are performed in a trusted environment such as a bank branch office. In addition, the bank officer might verify the identity of the person before completing the transaction. The electronic counterparts will require extremely strong authentication, such as public key cryptography (PKI) and/or biometrics to mitigate identity risk. In addition, the onus is on the enterprise to prove the absence of tampering after the transaction was processed. Sophisticated authorization based on transaction context will be required. Class IV transactions must be able to address the: who, what, where and when of the transaction. It is necessary to have a tamper proof audit trail of these transactions. Tamper proof audit trails ensure that at any time an enterprise can determine who had access to what data, how it was accessed, and how it was used. Tamper proof audit trails must be able to track access at a high level of granularity-data element level security is preferred. Similar to Class III, these transactions need to support multiple signatures in a defined process environment. Transaction transportability, in addition to back-end systems integration, is a requirement as well (Figure 2). Perceived Barriers Enterprises perceive there are cultural and legal barriers that prevent migrating higher risk paperbased transactions to the digital world. Cultural Barriers Perceived cultural barriers have inhibited the adoption of electronic signatures. These include adapting business processes to accommodate a new kind of signature, and the acceptance of digital technology in general. The requirement for handwritten original signatures is often the biggest delay in paper-based transactions, yet enterprises around the world continue to conduct business in this manner. Customers have become more comfortable with electronic transactions with the advent of the Internet. The velocity with which cultural barriers are breaking down is evident through the progress made by e-tailer Amazon.com, which in less than five years has grown bigger than brick and mortar retailer Sears. Consumers are also becoming accustomed to self-service in supermarkets and retail stores throughout the country. At Wal-Mart consumers get out of the store faster through the self-service checkout by signing on electronic signature pads. Users are becoming comfortable with transacting in the digital world, whether it's through self-service checkout lines at a brick and mortar store like Wal- Mart or the cyber world that Amazon.com occupies. Cultural barriers are dissolving as consumers recognize that electronic signatures are the path to fast, convenient, and secure electronic transactions. Legal Barriers Since electronic transactions are not yet supported by centuries of legal precedent, organizations fear the inability to legally enforce them in a court of law. This is exacerbated, as the digital world knows no boundaries. The global nature of electronic commerce brings into question the legal enforceability of transactions from one nation state to another. As governments around the world recognize electronic signatures, we are seeing legal barriers toppling on a global scale. The U.S. Congress passed the Electronic Signatures in Global and National Commerce Act (ESIGN) in June The primary intent of the law is to spur e-commerce and e-government by clearing legal barriers to electronically signed transactions. A key provision of the act is, "with respect to any transaction in or affecting interstate or foreign commerce," a E-Sign Transactions Platform Page 5

6 signature may not be denied legal standing "solely because it is in electronic form." The Federal Government Paperwork Elimination Act (GPEA) also encourages the use of electronic signatures. Various countries including Australia, Canada, China, Singapore, India and those in the European Union have also passed legislation recognizing the legality of electronic signatures. Historically, legal uncertainty about the enforceability of an electronic signature in a court of law was cited as a major barrier to many enterprise automation projects. Today these barriers are falling as a result of legal precedent and governmental regulations. Technical Challenges Inhibiting Migration of Higher Risk Transactions It is evident that the resistance to migration of highrisk paper transactions to electronic transactions is not primarily due to legal or cultural barriers. Indeed the reluctance of enterprises to digitize high-risk paper transactions can be attributed to solution architectures lacking: 1. Comprehensive Security 2. Compliance with legal requirements 3. Ability to meet the enterprise intelligence needs This section will outline the key technical requirements needed to enable migration of high-risk paper transactions to electronic transactions: Comprehensive Security The architecture needs to address the following security requirements: a)uniquely identifying the user: It must be possible to uniquely and unambiguously identify users who perform specific activities within the scope of a business transaction. Users must be issued unique identities and the application must authenticate users so as to associate them with their unique digital identity. b) Linking an activity performed on a business transaction to the user: An activity performed during a business transaction must be related to the user in an unambiguous fashion. c) Ensuring that access is restricted: The system must verify that the authenticated user has appropriate privileges to access the electronic transaction. Compliance with Legal Requirements a) Ensuring that the user is provided with appropriate information to understand the intent of the signature: The user must be made aware of the intent and significance of the electronic signature that binds the user to the specific activity the user is performing. b) Verifying a user's signature and recording the verification responses: To ensure that a user's signature has not been tampered with and to make sure that the signer's credentials are valid, it is necessary to verify the signature and validate the user's credentials. For enforceability, it is necessary to record the signature verification details. c) Keeping records of all activities and providing evidence of the activities when needed: For enforceability of a business transaction, the system must record all actions. The record itself must be protected from tampering. The system must provide tools to produce evidence of these actions in the future. Ability to Meet the Enterprise Intelligence Needs The architecture should leverage existing enterprise IT investments, while delivering a flexible yet strong security solution: a)rule based system to support varied enterprise processes: The electronic process must initially mimic the paper-based workflow process for quick adoption. At the same time, the system must provide tools to re-engineer the workflow processes, as well as define and enforce organizational rules to manage transaction risk. b)intuitive User Interface: Moving from a paper-based process to an electronic one can be daunting for some end users. For successful adoption, the solution must use familiar interfaces such as a web browser and support both Hyper Text Markup Language (HTML) and Adobe Portable Document Format (PDF) presentation formats. In addition, the system should support E-Sign Transactions Platform Page 6

7 electronic pad technology to ease migration from handwritten signatures to electronic signatures. c)easy to integrate with existing applications: Enterprises have invested heavily in their core enterprise architecture and require solutions that will easily integrate with existing applications. Organizations should be able to leverage their existing IT investments such as directory services, PKI, workflow and document management systems. TWO FEASIBLE ARCHITECTURAL APPROACHES There are two architectural approaches for migrating paper-based business processes to the digital world: the document-centric architecture and the transaction-centric architecture. Document-Centric Architecture Overview The focus of the document-centric architecture is on content creation and presentation. The document-centric approach tightly couples the presentation with the data. The basis of this approach is a self-contained document making it ideal for secure content presentation. The term Self-contained document implies the presentation is tied to a particular presentation application. An overview of the architecture is provided in Figure 3. Whenever electronic signatures are required the entire document is cryptographically sealed. Recipients of the document can verify signatures affixed by the sender. At the same time, if the recipients need to add data to the document, they have to create a different version of the document and sign the entire document. This is required because changing the original document will Figure 3 Document Centric Architecture TRANSACTION PROCESSING SYSTEMS GRAPHICAL USER INTERFACE HR SYSTEMS AUDIT HTML PAGE FINANCE SYSTEMS AUDIT ADOBE PDF CALL CENTER SYSTEMS AUDIT MS WORD Processing Presentation Audit APPLICATION LAYER Signature Ceremony Signature Signed Receipt PRESENTATION LAYER Figure 4 Transaction Centric Architecture TRANSACTION PROCESSING SYSTEMS TRUSTED TRANSACTION ENGINES GRAPHICAL USER INTERFACE HR SYSTEMS FINANCE SYSTEMS CALL CENTER SYSTEMS Processing APPLICATION LAYER RULES EVALUATION DATA PRESENTATION SIGNATURE VERIFICATION RULES VALIDATION AUDIT (DATA + PRESENTATION) ROUTING NOTIFICATIONS INFRASTRUCTURE DATA + HTML PAGE DATA + ADOBE PDF DATA + INFOPATH PAGE Signature Ceremony User Signature Signed Receipt PRESENTATION LAYER E-Sign Transactions Platform Page 7

8 invalidate the sender's signature. In addition, the business application needs to be enhanced to integrate the document presentation software and to implement new security rules. More importantly, each application has to build a secure audit function. Typically this is the first step that enterprises take when they decide to implement an electronic signature solution. As the document centric approach mimics the paper world it eases the adoption and acceptance of electronic signatures. Transaction-Centric Architecture Overview The focus of the transaction-centric architecture is on content processing based on enterprise business policy. The basis of the transaction-centric approach is the separation of data from presentation, and understanding of data semantics that enables definition and enforcement of enterprise business policies. An overview of this architecture is presented in Figure 4. The transaction-centric architecture is presentation agnostic allowing a choice of presentation formats. The transaction schema is provided to the 'Transaction Engines' enabling security, compliance and intelligence rule definition. The architecture allows enterprises to define data field level security and compliance rules. For example, restricting access to data elements rather than the entire transaction. The application passes the transaction data to the Transaction Engines at run-time. The Transaction Engines enforce the security, compliance and intelligence rules defined previously. Electronic signatures are implemented by cryptographically sealing individual data elements linked with the presentation template. This approach ensures that adding data to a transaction after it has been signed does not invalidate the electronic signature(s). The transaction-centric approach supports n-tier architecture. In addition, because the 'Transaction Engines' are an extension of the enterprise infrastructure they can enforce enterprise business policies across all applications. EVALUATION CRITERIA The objective of this section is to better define the key requirements identified in the section Technical Challenges in order to compare the two architectural approaches. As previously outlined, the primary requirements are: 1. Comprehensive security 2. Compliance with the legal requirements 3. Ability to meet the enterprise intelligence needs Let us examine in depth each of the fundamental requirements: Comprehensive Security Enterprise security requirements can be broadly categorized as follows: Risk Mitigation Independent of Business Applications Enterprises will either enable existing applications or build new applications to digitize paper-based transactions. The new electronic transactions have a higher risk profile. The primary risk is the electronic identity assurance of the entity that is transacting. Enterprises can improve the appropriate level of assurance they need by using multiple factors of authentication: (a) what you know (b) what you have and (c) who you are. At the same time, enterprises recognize that always requiring a three-factor authentication is not a cost effective solution. Enterprises will have to define new security rules for these new types of transactions. To make it an effective solution, rules implementation should be centrally administered as well as not require changes to existing applications. For example, a simple rule for a bank could be as follows: 'If it is a wire transfer, a PKI credential is required. If it is account opening, a 3rd party credit check is required. Preserve Integrity While Data is Augmented Even a simple business transaction such as approval of a vacation request requires multiple signatures. These signatures have different functions and are generally performed in the context of an organizational workflow that defines roles and responsibilities. In the paper world, each signatory only signs their data, and effectively vouches for the integrity of their data. People can change or add information to the document as long as the original signature is not compromised. The solution should meet the requirement of multiple valid electronic signatures on the same document. More importantly, E-Sign Transactions Platform Page 8

9 the document integrity cannot be compromised while the document is being changed in a workflow, and additional signatures are added Data-Field Level Privacy The law requires many enterprises to protect certain sensitive elements of a document from its various recipients. For example, in an e-commerce transaction, a 'web' merchant does not need to know a credit card number. The merchant only needs to know that the issuing bank has authorized the transaction. This type of requirement is usually met by encrypting the sensitive data; so only authorized recipients can decrypt it. Compliance with the Legal Requirements In the United States, the solution should be compliant not only with E-Sign, but also the UETA law passed by many states. The primary requirements are: Obtain consent if it is a customer-facing transaction Ensure that the end-user understands the intent of signing the transaction The signature should be unique The signature must be under the sole control of the signer The signature should be verifiable The signature should link the document and the signature, such that tampering can be detected Most of these requirements are addressed by a combination of authentication and cryptographic techniques. For example: A user-id/password can be unique, Creating a cryptographic hash on a document ensures integrity Digital signature can be verified Ability to Meet the Enterprise 'Intelligence' Needs: Today enterprises must deal with multiple external entities and support various business units. As a result enterprises require an intelligent IT architecture to mitigate their business risk. We will look at the primary requirements in this area: Single Framework Supporting Multiple Presentation Formats Enterprise applications typically support different delivery channels and thus have to support different presentation formats. The solution should offer a platform that supports multiple formats easily. For example, a financial services organization will need to support an HTML format for on-line banking transactions, an off-line MS/Windows GUI to support field sales and an Adobe PDF Form for retail financial center processing. Content Based Rules Enterprises process the same transaction type differently based on the value of the transaction. For example, a financial services organization will require a signature to be notarized if the amount of withdrawal exceeds $10,000. The solution should provide a framework where such rules can be implemented and if necessary tied to the risk mitigation rules mentioned above. The wire transfer rule could be as follows: 'If it is a wire transfer of more than $10,000, then an electronic notary in addition to a PKI credential is required, otherwise a PKI credential is sufficient. End-to-End Integration Enterprises want to integrate trusted transactions with their existing business applications. These business applications could be legacy applications or commercial off-the shelf (COTS) applications that cannot be modified. The solution should at a minimum support a standards based message format along with a loosely coupled integration model. An optimal solution would have adapters for standard middleware platforms such as IBM/MQ or WebMethods. Trusted Data Exchange Between Enterprises Certain business transactions will need to cross enterprise boundaries. For example, major commercial airlines have to submit their aircraft maintenance records to the FAA. The authorized mechanic must sign electronic records that can be processed by the FAA. The solution should implement an industryrecognized digital signature standard that can be independently verified by an external party. In addition, the solution should be able to transmit the data so that the trading partner can process it once E-Sign Transactions Platform Page 9

10 the signature is verified. Many industry associations, such as Mortgage Industry Standards Maintenance Organization (MISMO) have identified the W3C XML-Dsig as the standard for signing documents. COMPARISON OF APPROACHES Having established the criteria for comparison the two architectures can now be evaluated. Figure 5 is a summary comparison of the two approaches based on the ability to complete automation of business processes. Risk Mitigation Independent of Business Applications The Document-centric approach is limited in its ability to manage risk as it is based on a specific presentation application. This forces the business application to be enhanced to mitigate the transaction risk. In contrast the transaction centric architecture can enforce business rules independent of applications because the transaction data semantics are understood. Preserve Integrity While Data is Augmented There is a significant difference in the design philosophy of the two approaches when it comes to preserving integrity. The document-centric approach focuses on cryptographically encrypting the document as a whole rather than the data. It is impossible to maintain integrity of data once the data has been striped from the document. In contrast, the individual data elements are being cryptographically sealed in the transaction-centric approach. This enables addition of new data without invalidating the electronic signature computed on previous data items. Also, if a data field that was not signed previously was modified, this data can be later signed without invalidating the signature. Data Field Level Privacy The transaction-centric architecture enables data field level encryption and decryption offering field level access control. The document-centric architecture cannot offer this choice. Regulatory and Legislative Compliance Both architectures have to be compliant with the regulatory and legal requirements to enable migration of paper-based authorizations to the digital world. Single Framework Supporting Multiple Presentation Formats A transaction-centric model's primary design goal is to enable multiple presentation formats by separating presentation from data. A document-centric approach is built for a specific format and does not meet this requirement. Figure 5 Comparison of Transaction-Centric and Document-Centric Architectures REQUIREMENT Risk Mitigation Independent of Business Applications Preserve Integrity while Data is Augmented Data-Field Level Privacy Regulatory and Legislative Compliance Single Framework Supporting Multiple Presentation Formats Content-Based Rules End-to-End Integration Trusted Exchange Between Enterprises TRANSACTION DOCUMENT E-Sign Transactions Platform Page 10

11 Content-Based Rules The very nature of understanding transaction data enables content-based rule definition and enforcement. On the other hand, in the document-centric approach data and presentation are bundled together, making it difficult to identify content-based rules. End-to-End Integration The document-centric approach is built for proprietary presentation technologies such as MS/Word or Adobe/PDF. As a result, it cannot be easily integrated with disparate IT systems throughout the enterprise or with external partners. The transaction-processing model is based on understanding data semantics and separating presentation from data. Data integration is easy with the transaction-centric model. Trusted Data Exchange between enterprises The document-centric approach necessitates separating data from the document for data processing. Given the design it is impossible to maintain the integrity of data once the data has been stripped from the document. The design philosophy of the transaction-centric approach is to separate data and presentation, facilitating data processing after signatures have been validated. CONCLUSION Enterprises can address the challenges of Complete Business Process Automation, by digitizing the pape-based signature process. Meeting business requirements to digitize paper based signature processes, requires enterprises to: (1) provide a comprehensive transaction security framework, (2) be compliant with legislative and regulatory guidelines and (3) be able to meet the enterprise Intelligence needs.the ideal architecture consists of the three integrated Trusted Transaction engines described in this paper. The transaction-centric architecture allows presentation and processing flexibility because the architecture is based on the separation of data and presentation. In addition, it enables enterprise business policy enforcement without impacting the business applications. The transaction-centric architecture is a flexible architecture that scales from departmental solutions to enterprise implementations while satisfying the security, compliance, and intelligence needs of different transaction classes. The document centric architecture is not scalable for enterprise solutions and is appropriate only for departmental systems implementing a point solution. Figure 6 Transaction-Centric Architecture meets enterprise Requirements DOCUMENT CENTRIC TRANSACTION CENTRIC COMPLIANT Data Presentation Edit Rules COMPLIANT Risk Mitigation Independent of Applications Preserve Integrity while Data is Augmented Date Field Level Privacy Single Framework Supporting Multiple Presentation Formats Content-based Rules End-to-End Integration Dulles Technology Drive Suite 200 Herndon, Virginia 20171, US Exostar. All rights reserved E-Sign Transactions Platform Page 11