David Whitaker: Managing Your Vendors


Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

David Whitaker: Managing Your Vendors

  1. 1. So You Want to Take Your Business Electronic – Managing Your Vendors R. David Whitaker Senior Company Counsel Strategy and Operational Risk Group Wells Fargo Bank, N.A. Washington, D.C. November 9, 2010
  2. 2. Agenda <ul><li>Build vs. Buy </li></ul><ul><li>Assessing Needs </li></ul><ul><li>Assessing Vendors </li></ul><ul><li>Contracting </li></ul><ul><ul><li>Generally </li></ul></ul><ul><ul><li>Purchasing ASP services </li></ul></ul>© 2010 R. David Whitaker. All rights reserved. No copyright claimed on images licensed from others. No part of this document may be reproduced or transmitted in any form, by any means (electronic, photocopying, recording or otherwise) without the express prior signed permission of the author. This presentation is for purposes of education and discussion. It is intended to be informational only and does not constitute legal advice regarding any specific situation, product or service.
  3. 3. Assessing Needs Assembling an Assessment Team <ul><li>The proper development of an electronic process for records and signatures is necessarily a group effort. Gather a “system design team” composed of personnel from a variety of disciplines, including: </li></ul><ul><ul><li>Line of business representatives </li></ul></ul><ul><ul><li>Information technology </li></ul></ul><ul><ul><li>Info security </li></ul></ul><ul><ul><li>Product development </li></ul></ul><ul><ul><li>Marketing </li></ul></ul><ul><ul><li>Compliance </li></ul></ul><ul><ul><li>Legal </li></ul></ul><ul><li>The earlier the necessary participants are identified and integrated into the development process, the better. </li></ul>
  4. 4. Using in-house resources <ul><li>Tend to have a better grasp of business needs </li></ul><ul><li>Less likely to have labor-based cost overruns </li></ul><ul><li>Build off existing relationships </li></ul><ul><li>Solid understanding of existing systems </li></ul><ul><li>Better grasp of industry standards/practices (sometimes) </li></ul><ul><li>Experience with other implementations – often can suggest innovative problem-solving strategies </li></ul><ul><li>May have turn-key solutions for portions of the project </li></ul><ul><li>More likely to introduce, or be open to, new approaches </li></ul><ul><li>In-house expertise may simply not exist </li></ul>Assessing Needs Build vs. Buy Using outside vendors
  5. 5. Assessing Needs Build vs. Buy -- Key Factors to Consider <ul><li>Cost and complexity to support ongoing in-house development to meet changing functionality targets (hardware and application re-engineering) </li></ul><ul><li>Need for customized features or interface </li></ul><ul><li>Development and execution risk of custom development </li></ul><ul><li>Comparative delivery cycles for build vs. buy </li></ul><ul><li>Project costs to build known functional gaps for systems integration between purchased solution and existing systems </li></ul><ul><li>Comparative cost of support </li></ul><ul><li>Adequacy of testing platforms </li></ul>
  6. 6. Assessing Needs Key Factors to Consider Secure Communication Record Management Responsibility & Reports Generate Deliver Store Manage Destroy Record Life Cycle Propagate Data Signing Records Extract & Index Data Create Audit Trails & Reports Secure and Consistent Record Management Active Data Processes Access Controls Quality & Integrity Controls Record Destruction Business Continuity Key Systems Issues Boilerplate Docs Transaction-specific Docs Audit Trails for Enrollment, Delivery/Signing Screen Shots & Process Flows Primary Record Categories Search and Report Capabilities Company Policies and Guidelines Industry Standards and Regulation
  7. 7. Assessing Needs Illustration – electronic delivery of documents <ul><li>Key Considerations </li></ul><ul><li>Will the records contain sensitive information? </li></ul><ul><li>Will the records contain required disclosures or notices? </li></ul><ul><li>Are multiple delivery methods possible/desirable? </li></ul><ul><li>Are there “phishing” or “pharming” issues to address? </li></ul><ul><li>Need to maintain control over display and audit trails? </li></ul><ul><li>Need to obtain ESIGN Consumer Consent? </li></ul><ul><li>Key Considerations </li></ul><ul><li>2 Factor Authentication required? </li></ul><ul><li>How will cross-system compatibility/communication issues be addressed? </li></ul><ul><li>How much of design will be automated or manual? </li></ul><ul><li>Is system intended for use with targets without prior electronic relationship with sender? </li></ul><ul><li>Regulatory requirements for timing, delivery, proximity, conspicuousness, forced review? </li></ul><ul><li>Key Considerations </li></ul><ul><li>Addressing electronic delivery channels </li></ul><ul><li>Agreement on what constitutes “sending” and “receipt” (Note some state UETAs limit variation by agreement) </li></ul><ul><li>Agreement on obligation to update electronic addresses </li></ul><ul><li>Managing bouncebacks and withdrawal of consent </li></ul><ul><li>Secure or Unsecure? </li></ul><ul><li>Push out in email/SMS, or send “ready notice” and pull behind firewall? </li></ul><ul><li>Embedded hyperlinks in “ready notice” email? </li></ul><ul><li>Permit target to set delivery preferences? </li></ul><ul><li>Permit target to designate multiple recipients? </li></ul><ul><li>Forced review or bypassable? </li></ul><ul><li>Enrollment / consent process </li></ul><ul><li>Audit trails and reporting </li></ul><ul><li>Transmittal message contents </li></ul><ul><li>Authentication process for access to secure data (if applicable) </li></ul><ul><li>Record generation and posting to delivery system </li></ul><ul><li>Message or notice generation/transmission </li></ul><ul><li>Record retention/destruction process </li></ul><ul><li>Record generation/posting </li></ul><ul><li>Establish agreement on delivery </li></ul><ul><ul><li>When deemed delivered </li></ul></ul><ul><ul><li>Delivery address </li></ul></ul><ul><ul><li>Obligation to update address </li></ul></ul><ul><li>Obtain ESIGN Consent </li></ul><ul><li>Generate records </li></ul><ul><li>Send notice or attachments </li></ul><ul><li>Provide opportunity to retain </li></ul><ul><li>Generate audit trail </li></ul><ul><li>Handle “bouncebacks” </li></ul><ul><li>Handle withdrawal of consent </li></ul>Design Delivery Design Choices Execution
  8. 8. Assessing Needs Illustration – Identifying regulatory issues and trends Recent Regulatory Activity <ul><li>U.S. Department of Education – Expanded regulations for use of electronic promissory notes on student loans </li></ul><ul><li>FRB – Final mandatory rules for electronic banking disclosures </li></ul><ul><li>FRB – Additional rules for open-end credit, including new electronic disclosure requirements </li></ul><ul><li>FFIEC – Enhanced Authentication Guidelines </li></ul><ul><li>FTC Staff Report on improving mortgage disclosures </li></ul><ul><li>FTC Inquiry on use of SSN </li></ul>Key Trends <ul><li>Mandatory use of non-bypassable hyperlinks for certain disclosures (FRB & FTC) </li></ul><ul><li>Mandatory electronic delivery of disclosures in connection with electronic applications (FRB) </li></ul><ul><li>Required archiving of online process flows and screen shots for future introduction into evidence (Dept. of Education) </li></ul><ul><li>Elimination of ESIGN consumer consent requirement prior to delivery of some advertising disclosures (FRB) </li></ul><ul><li>Endorsement of hyperlinking for delivering detailed disclosures in conjunction with banner ads (FRB) </li></ul><ul><li>Enhanced emphasis on bank’s responsibility to protect customer identity and prevent fraud (FFIEC & FTC) </li></ul>
  9. 9. Assessing Vendors Overview Vendor Selection Score and Evaluate RFP Responses/Gap Analysis Select and “Sandbox” Finalists Contract Negotiation Gather Requirements Build RFP Build Scoring Model Identify RFP Vendors Iterative Process Key Element
  10. 10. Assessing Vendors Assembling an RFP Gathering Requirements <ul><li>Desired Functionality </li></ul><ul><ul><li>Business Functions </li></ul></ul><ul><ul><li>Scalability </li></ul></ul><ul><ul><li>Active Data Processes </li></ul></ul><ul><ul><li>Access Management </li></ul></ul><ul><ul><li>User Interface </li></ul></ul><ul><ul><li>Record Structure </li></ul></ul><ul><ul><li>Record Management </li></ul></ul><ul><ul><li>Audit trails </li></ul></ul><ul><ul><li>Business Continuity </li></ul></ul><ul><li>Integration Plans </li></ul><ul><li>Information Security </li></ul><ul><li>Legal Considerations </li></ul><ul><li>Third-party Requirements </li></ul>Building the RFP <ul><li>Vendor History </li></ul><ul><li>Vendor Financial Condition </li></ul><ul><li>Vendor Alliances and Dependencies </li></ul><ul><li>IP Ownership </li></ul><ul><li>Functionality </li></ul><ul><li>Integration Capabilities </li></ul><ul><li>Custom Design Capabilities </li></ul>
  11. 11. Assessing Vendors Scoring Building a Scoring Model <ul><li>Create a score sheet listing out the questions and specifications you have asked vendors to respond to. </li></ul><ul><li>Set out desired “perfect” answers for each specification or question. </li></ul><ul><li>Have SMEs establish both point ranges and weighting for responses in their areas of expertise. </li></ul>Scoring <ul><li>Segregate RFP responses by categories relevant to your own SMEs. </li></ul><ul><li>Have SMEs score responses in the categories they are responsible for. </li></ul><ul><li>Keep score totals for each vendor and for the different categories sequestered until scoring analysis is complete. </li></ul><ul><li>Evaluate scores </li></ul>
  12. 12. Evaluating RFP Responses Key Strategies for Picking Finalists <ul><li>“Scoring is only the beginning…” </li></ul><ul><ul><li>Scores offer insights, but not answers </li></ul></ul><ul><ul><ul><li>Scores highlight strengths and weaknesses </li></ul></ul></ul><ul><ul><ul><li>Point to areas where further scrutiny makes sense </li></ul></ul></ul><ul><ul><ul><li>Provide a general sense of leading candidates </li></ul></ul></ul><ul><li>Consider: </li></ul><ul><ul><li>Strategic relationships already in place (yours and theirs) </li></ul></ul><ul><ul><li>Financial condition </li></ul></ul><ul><ul><li>Existing customer base </li></ul></ul><ul><li>With leading candidates: </li></ul><ul><ul><li>Arrange for demonstrations and “sandboxing” </li></ul></ul><ul><ul><li>Begin contract discussions </li></ul></ul>
  13. 13. “Sandboxing” – Objectives <ul><li>To validate that key performance and functional requirements can be met with the Vendor solution (products, services, hardware) </li></ul><ul><li>Key Non-Functional Requirements </li></ul><ul><ul><li>High Availability </li></ul></ul><ul><ul><li>Scalability </li></ul></ul><ul><ul><li>Performance </li></ul></ul><ul><li>Key Functional Requirements </li></ul><ul><li>Key Partnership Objectives </li></ul><ul><ul><li>Partnership with key vendor teams (services, </li></ul></ul><ul><ul><li>product development, pre-sales, hardware) </li></ul></ul>
  14. 14. “Sandboxing” Process <ul><li>Multiple Days of Testing </li></ul><ul><li>Production-Like Environment </li></ul><ul><li>Stress and Volume Testing </li></ul><ul><li>User Experience Testing </li></ul><ul><li>Results Summary </li></ul>
  15. 15. <ul><li>Lessons Learned </li></ul><ul><li>System Test </li></ul><ul><li>Validated Components </li></ul>Phase n Phase 2 System Test Project Steps Phase 1 Deployment Testing Tools and Acceptance Process User Test and Training Install, Build and Develop Solution Design Requirements Collection Sand- box “ Sandboxing” – Functional and System Test Use Cases USE CASES
  16. 16. Extra Issues for ASP Providers <ul><li>Beware the Cloud </li></ul><ul><ul><li>Dedicated </li></ul></ul><ul><ul><li>Multi-Tenant </li></ul></ul><ul><li>Info Security </li></ul><ul><ul><li>Physical Security </li></ul></ul><ul><ul><li>Access Control </li></ul></ul><ul><ul><li>Code Review </li></ul></ul><ul><ul><ul><li>Usually reserved for sophisticated users </li></ul></ul></ul><ul><ul><ul><li>Frequently exposes security gaps </li></ul></ul></ul>
  17. 17. Be sure your contract covers… <ul><li>A detailed description of services and products </li></ul><ul><li>Warranties reflecting promises made </li></ul><ul><li>Exit strategies for </li></ul><ul><ul><li>Inadequate service </li></ul></ul><ul><ul><li>Breach of warranty </li></ul></ul><ul><ul><li>Merger or acquisition </li></ul></ul><ul><ul><li>Insolvency </li></ul></ul><ul><ul><li>Loss of key license </li></ul></ul><ul><li>Realistic time frames for exit </li></ul><ul><li>Realistic liability and indemnity </li></ul><ul><li>Protection against self-help remedies (beware MD and VA) </li></ul><ul><li>Protection against future price-gouging </li></ul>And for ASPs… <ul><li>Warranties reflecting the business model </li></ul><ul><li>Service standards and SLAs </li></ul><ul><li>Business Continuity Plans </li></ul><ul><li>For records held by vendor: </li></ul><ul><ul><li>Recognition of Information Ownership </li></ul></ul><ul><ul><li>Custodial obligations </li></ul></ul><ul><ul><li>Compliance with record retention/destruction schedules </li></ul></ul><ul><ul><li>Hell or high water data access clause </li></ul></ul><ul><li>And watch for </li></ul><ul><ul><li>Unrealistic liability limitations </li></ul></ul><ul><ul><li>Warranty disclaimers that contradict promises made </li></ul></ul>Contracting with a Vendor Cautions and Coverage