Market ReformProgramme Office

Standardised validation of ACORD messages

Rob Campbell

July 2007

Mark

et

Refo

rm

Page 2

Agenda

• Introduction

– Background

– Where are we now

• What is validation

• Why should validation be standardised

• Issues for discussion

Mark

et

Refo

rm

Page 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

Mark

et

Refo

rm

Page 4

Receiving organisation

Traditional validation

ACORD Standards

Market Implementatio

n specifications

Systems and business

specifications

Receive message (Gateway)

Process message

SchemasCore systems

Validation code

ACORD Standards

Mark

et

Refo

rm

Page 5

Receiving organisation

Introduction of standardised validation

Schemas

ACORD Standards

Market Implementatio

n specifications

Systems and business

specifications

Receive message (Gateway)

Process message

Core systems

Validation code

Validating stylesheets

ACORD Standards

Mark

et

Refo

rm

Page 6

XML Level Validation

Receiver

<XML>

Business Message

Application(s)

XML message-level processing

Application-level processing(XML or other)

Application level validation

Validating stylesheet(s)XML Schema(s)

Mark

et

Refo

rm

Page 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

Mark

et

Refo

rm

Page 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?

Mark

et

Refo

rm

Page 9

Cost implications

Complexity of messagingVolume, data richness, number of participants, processes covered

Co

st

Need for s

tandardised validatio

n

Initial c

ost to in

troduce standardised valid

ation

Cost of n

on-standardised validatio

n

Cost of standardised validation

Note: Cost curves intended as indication of accepted standardisation trends, not as representing quantitative data.

Mark

et

Refo

rm

Page 10

What is standardised validation

• 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

Message gateway

Generic capability

Validating stylesheet

2.

1.

Mark

et

Refo

rm

Page 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?

Mark

et

Refo

rm

Page 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.

Mark

et

Refo

rm

Page 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.