David Whitaker: Managing Your VendorsPresentation Transcript
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
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:
Line of business representatives
The earlier the necessary participants are identified and integrated into the development process, the better.
Using in-house resources
Tend to have a better grasp of business needs
Less likely to have labor-based cost overruns
Build off existing relationships
Solid understanding of existing systems
Better grasp of industry standards/practices (sometimes)
Experience with other implementations – often can suggest innovative problem-solving strategies
May have turn-key solutions for portions of the project
More likely to introduce, or be open to, new approaches
In-house expertise may simply not exist
Assessing Needs Build vs. Buy Using outside vendors
Assessing Needs Build vs. Buy -- Key Factors to Consider
Cost and complexity to support ongoing in-house development to meet changing functionality targets (hardware and application re-engineering)
Need for customized features or interface
Development and execution risk of custom development
Comparative delivery cycles for build vs. buy
Project costs to build known functional gaps for systems integration between purchased solution and existing systems
Comparative cost of support
Adequacy of testing platforms
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
Assessing Needs Illustration – electronic delivery of documents
Will the records contain sensitive information?
Will the records contain required disclosures or notices?
Are multiple delivery methods possible/desirable?
Are there “phishing” or “pharming” issues to address?
Need to maintain control over display and audit trails?
Need to obtain ESIGN Consumer Consent?
2 Factor Authentication required?
How will cross-system compatibility/communication issues be addressed?
How much of design will be automated or manual?
Is system intended for use with targets without prior electronic relationship with sender?
Regulatory requirements for timing, delivery, proximity, conspicuousness, forced review?
Addressing electronic delivery channels
Agreement on what constitutes “sending” and “receipt” (Note some state UETAs limit variation by agreement)
Agreement on obligation to update electronic addresses
Managing bouncebacks and withdrawal of consent
Secure or Unsecure?
Push out in email/SMS, or send “ready notice” and pull behind firewall?
Embedded hyperlinks in “ready notice” email?
Permit target to set delivery preferences?
Permit target to designate multiple recipients?
Forced review or bypassable?
Enrollment / consent process
Audit trails and reporting
Transmittal message contents
Authentication process for access to secure data (if applicable)
U.S. Department of Education – Expanded regulations for use of electronic promissory notes on student loans
FRB – Final mandatory rules for electronic banking disclosures
FRB – Additional rules for open-end credit, including new electronic disclosure requirements
FFIEC – Enhanced Authentication Guidelines
FTC Staff Report on improving mortgage disclosures
FTC Inquiry on use of SSN
Mandatory use of non-bypassable hyperlinks for certain disclosures (FRB & FTC)
Mandatory electronic delivery of disclosures in connection with electronic applications (FRB)
Required archiving of online process flows and screen shots for future introduction into evidence (Dept. of Education)
Elimination of ESIGN consumer consent requirement prior to delivery of some advertising disclosures (FRB)
Endorsement of hyperlinking for delivering detailed disclosures in conjunction with banner ads (FRB)
Enhanced emphasis on bank’s responsibility to protect customer identity and prevent fraud (FFIEC & FTC)
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
Assessing Vendors Assembling an RFP Gathering Requirements
Active Data Processes
Building the RFP
Vendor Financial Condition
Vendor Alliances and Dependencies
Custom Design Capabilities
Assessing Vendors Scoring Building a Scoring Model
Create a score sheet listing out the questions and specifications you have asked vendors to respond to.
Set out desired “perfect” answers for each specification or question.
Have SMEs establish both point ranges and weighting for responses in their areas of expertise.
Segregate RFP responses by categories relevant to your own SMEs.
Have SMEs score responses in the categories they are responsible for.
Keep score totals for each vendor and for the different categories sequestered until scoring analysis is complete.
Evaluating RFP Responses Key Strategies for Picking Finalists
“Scoring is only the beginning…”
Scores offer insights, but not answers
Scores highlight strengths and weaknesses
Point to areas where further scrutiny makes sense
Provide a general sense of leading candidates
Strategic relationships already in place (yours and theirs)
Existing customer base
With leading candidates:
Arrange for demonstrations and “sandboxing”
Begin contract discussions
“Sandboxing” – Objectives
To validate that key performance and functional requirements can be met with the Vendor solution (products, services, hardware)
Key Non-Functional Requirements
Key Functional Requirements
Key Partnership Objectives
Partnership with key vendor teams (services,
product development, pre-sales, hardware)
Multiple Days of Testing
Stress and Volume Testing
User Experience Testing
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
Extra Issues for ASP Providers
Beware the Cloud
Usually reserved for sophisticated users
Frequently exposes security gaps
Be sure your contract covers…
A detailed description of services and products
Warranties reflecting promises made
Exit strategies for
Breach of warranty
Merger or acquisition
Loss of key license
Realistic time frames for exit
Realistic liability and indemnity
Protection against self-help remedies (beware MD and VA)
Protection against future price-gouging
And for ASPs…
Warranties reflecting the business model
Service standards and SLAs
Business Continuity Plans
For records held by vendor:
Recognition of Information Ownership
Compliance with record retention/destruction schedules
Hell or high water data access clause
And watch for
Unrealistic liability limitations
Warranty disclaimers that contradict promises made