DTCC Web Services Implementation

Transcription

1 DTCC Web Services Implementation ACORD Implementation Forum November 4, 2009

2 Session Agenda DTCC Insurance & Retirement Services Overview ACORD Messages Supported by DTCC Web Services Design and Features Challenges/Lessons Learned ACORD TCF Demo Audience Discussion

3 Overview of DTCC DTCC is the holding company for registered clearing agencies: DTC, NSCC, and FICC. These subsidiaries serve as the principal post-trade infrastructure for the US financial systems, handling clearance and settlement of virtually all trades in equities, corporate and municipal bonds, money market instruments, and the majority of U.S. government and mortgage-backed securities. Serves and is connected to a network of almost 3,000 brokersdealers, banks, clearing firms, mutual funds, insurance companies, service providers and vendors. Owned by its users, run as not-for-profit.

4 Insurance and Retirement Services Overview Division of NSCC Established in 1997 Link Insurance Carriers with Broker/Dealers, Banks, and other Distributors of insurance products Provide automated, centralized and standardized framework for information (data) exchange and money settlement Support primarily variable annuity products Additionally support other annuity types, life and LTC

5 Value Proposition Reduce operating costs by eliminating paper and manual processes Automate, standardize and streamline insurance processing and information exchange between carriers and broker-dealers Help establish and automate compliance procedures Aggregate money settlement: reconciliation of applications to premium dollars, and applications to commissions paid Help distributors and carriers grow revenue

6 Operational Benefits Distributor A Distributor B Distributor C DTCC Model Automated processing solution with a single point of entry, addressing the needs of both insurance carriers and distributors Central link Trading Trading Trading Efficient Partner X Partner Y Partner Z Distributor Distributor Distributor A B C Proprietary Model Distributors and carriers use their own direct lines with multiple trading partners Inefficient Time Consuming Trading Partner Trading Partner Trading Partner X Y Z

7 Our Current Business Landscape 58 Insurance Carrier Families 166 Companies 211 Distributors 30 Vendors & Service Providers Settled 38 billion dollars Networked over 3.4 billion policies 9 different products/services

8 Current Insurance Functionality Agent Services Licensing & Appointments (LNA) LNA Access sm Commissions (COM) Monitoring & Reporting Positions & Valuations (POV) Asset Pricing (AAP) Financial Activity Reporting (FAR) Pre-Issue Services Applications & Premium (APP) Attachments (ATT) Replacements (RPL) In-Force Transactions Automated Customer Account Transfers / Insurance Processing Services (ACATS/IPS) Registered Representative (REP) Broker Identification (BIN) Subsequent Premium (SUB) Fund Transfers (FTR) IFT Access sm

9 Services using ACORD Messaging Fund Transfers Applied ACORD messages: TXLife 212 (Values Inquiry Request) TXLife 102 (Fund Transfers Request) Attachments Applied ACORD messages: TXLife 510 (Forms Instance Request) Replacements Applied ACORD messages: TXLife 127 (Replacement Processing Request) (Replacement Notify) (Replacement Request for Surrender) (Replacement Cancellation) (Supplementation Information to a prior Request) 12705* (Replacement content Purge) TXLife 1128 (Replacement Processing Update) TXLife1125 (Case Status Notification Transmittal)

10 Fund Transfers Automates one-time fund exchange of underlying securities within a variable insurance contract. Enables distributors to enforce controls and reporting on rep activities for fund transfers. The fund transfer transaction enables the automated processing of a fund transfer and update/changes to impacted service features that exist within a contract. A values inquiry message is available for firms to get the latest policy information prior to submitting the fund transfer. The implementation of both the fund transfer and values inquiry message is architected in real-time and uses ACORD XML standard messages.

11 Attachments A stand alone process for participating members to electronically communicate attachment messages of imaged documentation, electronic signatures or electronic forms. Secure A more efficient, cost effective process for members that eliminates the need to send documents through postal mail or overnight carrier Supports all types of transactions including New Business, In Force Transactions, Licensing and Appointment as well as additional documentation for confirmations, statements, welcome packages and prospectuses.

12 Replacements Provides a centralized system for the automation and standardization of replacement processing between insurance carriers Incorporates the exchange of data messages for both qualified and non-qualified replacement and 1035 exchanges for fixed annuities and variable annuities. Architected utilizing ACORD standard messages. Includes money settlement processing between insurance carriers, case status reporting to distributors and the ability to attach the required electronic documents to the request message.

13 Replacements Functionality exist today, outside of project scope Within project scope Replacement Notification ** = Process may require sending supporting paperwork manually APP Submission ** APP Submission D i s t r i b u t o r New Business Submission message (including Replacement data) ** (TXLIfe # 103) New Business Submission - Manual process ** ** Supporting Paperwork (Forms) Manual process via FAX, Mail, etc... R e c e I v I n g C a r r I e r Replacement Notification message (with Attachments) (TXLife 127) TXLIfe Response Messages - (Edits: Accepts/ Rejects) - ( Kill message) TXLife 1128 N S C C I P S TXLife 127 Replacement Processing Update message (TXLIfe 1128) TXLIfe Response Messages - (Edits: Accepts/ Rejects) - (Kill message) D e l I v e r I n g C a r r I e r NSCC Money Settlement

14 Project Plan DTCC creates a White Paper to float idea Form Work Group with industry participation Document current process Document proposed process Set business process rules Determine ACORD messages to suit process Mapping of ACORD Form (i.e. to Replacement message) Maintenance Requests Draft Implementation Guides Sub Groups for targeted tasks (as needed) Form Pilot Group Commit to implement with DTCC and your pilot peers Decision maker set standards and best practice Finalize and expand on efforts of Work Group ACORD Maintenance Requests Finalize documentation (Business Requirements, Implementation, Connectivity and Technical Guides) Migrate to Participant Test Environment Pilot peer testing, first mover testing, future participant testing Migrate to Production

15 Web Services Design SOA model, acting as a hub to our participants and provide connectivity to services that are exposed at their trading partners. Security Model Inbound 2 way SSL Outbound 1 way SSL Digital Certificate Authentication

16 2 way SSL authentication Content source: IBM

17 1 way SSL Content source: IBM

18 Web Services Design MTOM for attachments

19 What is MTOM? MTOM is the W3C Message Transmission Optimization Mechanism, a method of efficiently sending binary data to and from web services. It uses XOP (XML-binary Optimized Packaging) to transmit binary data and is intended to replace both MIME and DIME attachments. Binary content often has to be re-encoded to be sent as text data with SOAP messages. MTOM allows more efficient sending of binary data in a SOAP request or response.

20 Why use MTOM? Efficient Transmission: Base64Binary encoded data is ~33% larger than raw byte transmission using MIME. MTOM therefore reduces data bloat by converting Base64Binary encoding to raw bytes for transmission. Processing Simplicity: Base64Binary encoded data is composed of 65 textual characters. The data is represented within an element of a SOAP message. Security standards such as WS-Signatures and WS-Encryption can directly be applied to the SOAP Message. Once such operations are performed, the Base64Binary data can be converted to raw bytes for efficient transmission. Securing document transmission via SOAP, therefore, does not require additional standards for securing MIME-based attachments. Content source: Crosscheck Networks

21 MTOM for Attachments How is MTOM Transformation done Content source: Crosscheck Networks

22 MTOM for Attachments Before: <soap:body> <tns:byteecho> <tns:data>jvberi0xljynjeljz9mncje+dqpzdgfyncjex0yncg==</tns:data> </tns:byteecho> </soap:body> After: <soap:envelope> <soap:body> <tns:byteecho> <tns:data><xop:include </tns:byteecho> </soap:body> </soap:envelope> --MIMEBoundary content-id: content-type: application/octet-stream content-transfer-encoding: binary Content source: Crosscheck Networks

23 MTOM and Schema Validation Before Applying MTOM schema validation: <xsd:element name="attachmentdata64binary" type="xsd:base64binary"/> After Applying MTOM schema validation: <xsd:element name="attachmentdata64binary" type="attachmentdata64_type"/> <xsd:complextype name="attachmentdata64_type"> <xsd:sequence> <xsd:element ref="xop:include"/> </xsd:sequence> </xsd:complextype> <xs:schema xmlns:xs=" xmlns:tns=" targetnamespace=" <xs:element name="include" type="tns:include" /> <xs:complextype name="include"> <xs:sequence> <xs:any namespace="##other" minoccurs="0" maxoccurs="unbounded" /> </xs:sequence> <xs:attribute name="href" type="xs:anyuri" use="required" /> <xs:anyattribute namespace="##other" /> </xs:complextype> </xs:schema>

24 Web Service Design Business Rules Validation Contract First approach to Web Design for WSDL and Schema creation. Sub-set of ACORD schema

25 Web Services Support Features Real-Time Secure Connectivity via DTCC SMART network ACORD Standards ACORD Testing Facility Message Simulators

26 Challenges/Lessons Learned Interoperability Issues Various web service frameworks in use with different interpretation of web service standards ( might help) Example Java vs..net, Mixed Message Encoding Differing experience levels with web services at companies Availability of test, debugging tools and error messages Network tracing Expertise of Human Resources Web Service Message Passing Message as Xml string (Fund Transfers Works this way) Only allows schema validation at runtime Message as schema object (Attachments & Replacements Works this way) Allows for design time schema validation Only way to support certain WS-I Profile Items (MTOM for example) Customer Support getting them involved in the process SOAP versions and Schema versions SOAP for both SOAP 1.1 and SOAP 1.2

27 Challenges/Lessons Learned *** SOAP *** Pros: Language, platform, and transport agnostic Designed to handle distributed computing environments Is the prevailing standard for web services, and hence has better support from other standards (WSDL, WS-*) and tooling from vendors Built-in error handling (faults) Extensibility Cons: Conceptually more difficult, more "heavy-weight" than REST More verbose Harder to develop, requires tools *** REST *** Pros: Language and platform agnostic Much simpler to develop than SOAP Small learning curve, less reliance on tools Concise, no need for additional messaging layer Closer in design and philosophy to the Web Cons: Assumes a point-to-point communication model--not usable for distributed computing environment where message may go through one or more intermediaries Lack of standards support for security, policy, reliable messaging, etc., so services that have more sophisticated requirements are harder to develop ("roll your own") Tied to the HTTP transport model

28 Challenges/Lessons Learned Future of Web Services: RESTful WebServices Vs SOAP Based Web Services and when to use either approach Plain XML Vs SOAP Contract based messages HTTP CRUD Equivalent ============================== GET read POST create,update,delete PUT create,update DELETE delete The REST request: GET /StockPrice/IBM HTTP/1.1 Host: example.org Accept: text/xml Accept-Charset: utf-8 The REST response: HTTP/ OK Content-Type: text/xml; charset=utf-8 Content-Length: nnn <?xml version="1.0"?> <s:quote xmlns:s=" <s:tickersymbol>ibm</s:tickersymbol> <s:stockprice>45.25</s:stockprice> </s:quote>

29 Challenges/Lessons Learned Future of Web Services: RESTful WebServices Vs SOAP Based Web Services and when to use either approach Plain XML Vs SOAP Contract based messages The SOAP request: GET /StockPrice HTTP/1.1 Host: example.org Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn <?xml version="1.0"?> <env:envelope xmlns:env=" xmlns:s=" <env:body> <s:getstockquote> <s:tickersymbol>ibm</s:tickersymbol> </s:getstockquote> </env:body> </env:envelope> The SOAP response: HTTP/ OK Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn <?xml version="1.0"?> <env:envelope xmlns:env=" xmlns:s=" <env:body> <s:getstockquoteresponse> <s:stockprice>45.25</s:stockprice> </s:getstockquoteresponse> </env:body> </env:envelope>

30 ACORD Testing Certification Facility

31 ACORD Testing Certification Facility

32 ACORD Testing Certification Facility

33 ACORD Testing Certification Facility

34 ACORD Testing Certification Facility

35 ACORD Testing Certification Facility

36 ACORD Testing Certification Facility

37 Thank You! Craig Gurien Office: Cory Stark Office: Website: