Standardised validation of ACORD messages

1. Standardised validation of ACORD messages Rob Campbell July 2007

2. Agenda • Introduction • Background • Where are we now • What is validation • Why should validation be standardised • Issues for discussion Page 1

3. What is validation • Gatekeeper • Protects receiving systems from erroneous data • Implements agreed rule standards • The question is not whether validation should be done. It must be performed and is already being performed • The question is how and where is it done … what are the cost and quality issues Page 2

4. Validation code Schemas Traditional validation Receiving organisation ACORD Standards ACORD Standards Market Implementation specifications Systems and business specifications Receive message (Gateway) Core systems Process message Page 3

5. Validating stylesheets Introduction of standardised validation Receiving organisation ACORD Standards ACORD Standards Market Implementation specifications Systems and business specifications Validation code Receive message (Gateway) Schemas Core systems Process message Page 4

6. XML Level Validation Receiver <XML> Business Message XML Schema(s) Validating stylesheet(s) XML message-level processing Application-level processing (XML or other) Application(s) Application level validation Page 5

7. Rationale for standardised validation • There are a number of key advantages to all parties using such standardised validation in a plug-and-play fashion: • ensures that defined rules are consistently implemented • prevents multiple recipients disagreeing on whether a message is valid • saves firms the cost of writing their own validation • speeds implementation and makes future changes easier to implement … avoids each firm having to change their validation code when changes are required • makes it easier and more reliable for different users to operate on different versions of ACORD messaging • provides an independent check on message validity during fault finding • makes it easier for organisations entering the market for the first time, to incorporate market-specific requirements into their systems Page 6

8. What sort of rules are we talking about • Different levels • Generic ACORD • Intra-message business rules • Market / trading partner rules • Examples • Does the value appear in the required Code list? • Is there is an (Re)Insurer Reference and (Re)Insurer party information if the message sender is the (Re)Insurer? • Is there a reference to a previous Placing message if this message is flagged as a replacement message? • Are the Endorsement details given where the message is flagged as an endorsement? • Do the contract sections follow the rules given in the standard? Page 7

9. Cost implications Initial cost to introduce standardised validation Need for standardised validation Cost Cost of non-standardised validation Cost of standardised validation Complexity of messagingVolume, data richness, number of participants, processes covered Page 8 Note: Cost curves intended as indication of accepted standardisation trends, not as representing quantitative data.

10. What it is 1. A generic capability independent of the validation rules 2. Independent, machine readable representation of agreed rules contained within the standard How it is used Processed by existing technology already implemented by some participants and vendors What it is NOT Software Computer system Prescribed technology What it does NOT do Introduce new standards or “Londonisms” Remove control What is standardised validation Message gateway Validating stylesheet 2. Generic capability 1. Page 9

11. Issues to explore • The role of ACORD • Ownership of a new standards deliverable? • Brings the implementation guides to life • Cost and exposure? • Incremental update effort with maintenance cycle added to XML Schema work • Servicing cost? • Relationship to ACORD’s TCF (Test and Certification Facility) • The same deliverable • Where to start? • Potential impact • Primarily a gateway supplier issue i.t.o. implementation (some already provide the capability) • Validating stylesheets already written • Error handling already in place. Some modification required? • Market review of rules? • Existing implementation, next message version change or next new implementation? • IMR (DRI)? • Placing messages? • A&S messages? • Sponsorship requirements and next steps? Page 10

12. Frequently asked questions • Why validate again? Isn’t ACORD certification enough? • Certification proves you are able to send and receive valid messages. It does not guarantee that the systems behind the messaging will always populate each message correctly. Validation is already being applied by those implementing messaging. This document merely examines a different way to perform some validation. • If we’ve already implemented validation won’t this be too costly? • There may be an initial cost, but over time the cost benefits will outweigh this. The initial cost is mitigated somewhat by the fact that the implementation is a “Gateway” issue. • Who will own the validating stylesheets? • Ownership will depend on what each stylesheet is representing: e.g. generic ACORD message, market specific rules or trading partner customisations. Ownership is still to be determined. • What happens if something goes wrong at midnight? Will the stylesheet owner be responsible? • The validating stylesheet is merely a lookup list issued as part of a standard. No servicing is required at this level. Failures in systems and gateways will continue to be serviced as at present. • Is anyone using this already? • The technology behind this is not new or unique. It is just another way of coding up validation into a computer system. Accordingly, some implementers have already implemented their message validation using this approach. However, in the absence of standardised validating stylesheets they have created their own. Page 11

13. Frequently asked questions contd. • Do I need particular technology or software to use the stylesheets described? • The technique is not proprietary to any particular technology or programming language • What happened to the “Lloyd’s / TriSystems Schematron”? • This was released as a beta version for DRI validation. It provided an example of how this validation may be used. A production version of this stylesheet has been produced. It’s release is currently being planned subject to resolution of outstanding issues around ownership and ongoing maintenance. • I want to continue validating some rules in my own application. Can I do so? • This can be done and, depending on the rules concerned may still have to be done in the application. However if the same rule is implemented as a standardised validation at your gateway any failure of this rule will result in a response being generated at the gateway before the message reaches your application. • All the validation I have built into my product gives me competitive advantage. Will this negate the investment I have made? • Not all rules are suited to standardised validation. Rules that are clearly expressed in the standard and require consistent application across the market should be validated in a standard way. You should benefit from the cost savings of not having to maintain these rules. • I want to see messages the have business level errors in them. I don’t want them rejected before they get to me. • There is nothing to stop failed messages being forwarded to the appropriate internal systems where this is possible. Rules can be defined as “errors”, “for_information” or “warning” thus allowing processing to continue while including commentary on detected failures. Page 12