EDI PROP Message.

With software systems in insurance brokers, price comparison site and insurers all being different back it was decided back in the late 1980s that a standard way of communicating between them was needed and was created, Brokernet.

Much of what was agreed then is still in use today because it works and changing it would be expensive and for little benefit.

However like all standards they are also restrictive, it is very difficult to create a radically different motor insurance policy because so many parties would have to agree on modifying the standards and their systems.

Although multi car insurance may sound new, it was catered for in the original standards, what was not catered for was a combined car/household insurance policy so implementing this would be a significant development.

However the Internet has allowed insurers to interact directly with customers, so while creating a combined car/household policy and selling it via a broker would be a huge project creating one on their own web site would not.

STX=ANA:1+0000:UnknownFrom+00001:UnknownUnto+072420:112738+000001++PROP05'
MHD=1+PROP05:2'
CID=A00000:UnkownFrom+A00001:UnkownTo'
SFI=0:WebSite:1.0:18052019:18052019'
SFT=1'
PLH=PN0000001+NPE:00:NPE:00+WS+24072020:120000+24072021:115959+123123++10000+40818961+Sch001+Auth001'
PYD=SF:CA+25002++22443++++++++23811'

This message is created using a very rigid format the + and : are field separators and the ' the end of line marker.

The + separates fields that must be present even if they have no values, hence the long string of them, this is necessary as all fields are defined by their position.

The : separates fields that are optional.

The MHD segment says what the message is, in this case the 1 is a sequence number of the message in the file, PROP05 means a new business message and the 2 is the variant of that message.

The PYD segment is payment details and each position's meaning is shown in the table.

Just to stress the point the meaning of a value is entirely depended upon where it appears, so both sides the sender and the receiver agree to this outside of the actual message.

Not only do both parties have to agree the position they also have to agree the format, for example PPCB is S9(8)V99.

You may notice that the fields from RTPA don't appear in the message above, it is allowed to end a segment early and all missing elements are assumed to be empty.

STX= - Start of Transmission
MHD= - Message Header
CID= - Communicators ID
SFI= - Software Identifier
SFT= - Software Identifier Trailer (count of SFIs) 
PLH= - Policy Header
PYD= - Payment Details

A full message consists of a lot more segments laid out like those shown.

A lot of people may now be screaming just use XML it is more flexible, superficially this is true but in reality it isn't.

The web has created a whole generation or even two of developers who have been brought up with if it works 95% of the time then that's the best we can hope for, unfortunately that is not good enough for insurance or banking,

The problem xml has is that while it is very easy to change a message it is much more complicated to process the changed message throughout systems controlled by various parties.

For example one insurer decides that it is important to know if the proposer is a pet owner as they want to offer a discount if he is.

They go to a price comparison site who agrees to add this question, the other sites are not asked nor the suppliers to high street brokers.

So all the other insurers would not be aware of this new XML Schema and would not have altered and tested their systems to support the has a pet question.

A hobbyist world would propably just say ignore the unknown bit about the pet but you can't do this in a system forming potentially very high value liabilities.

You can't just send the new message and expect all insurers to process it, even though it doesn't matter that they are not interested in the new question, because they need to test the new message to be sure that it still works with their systems.

As this is a cost with no benefit to them they won't do it.

After all if you don't know why there is a new message format then you don't know that the change doesn't matter to you, the new message may have contained something that you care about or the unexpected element may be indicative of an error.

So the new message would have to be sent only between these two parties.

If one insurers comes to one private agreement with one platform then fine, but once 20 insurers come to 15 different agreements with 25 providers developing and testing all of the message formats becomes unmanageable.

It is not the format that is the problem, it would be easy to invent a private PET=Y; segment in the existing EDI structure it's the fact that you need many parties to agree to handle multiple message formats.

Original message

<motorproposal>
    <driverdetails>
        <driver1>
            <name>Mr Ian Smith</name>
        </driver1>
    </driverdetails>
    <vehicledetails>
        <vehiclecode>53579303</vehiclecode>
    </vehicledetails>
</motorproposal>

could easily be changed to the xml message and its associated schema to one that supported the new question.

<motorproposal>
    <driverdetails>
        <driver1>
            <name>Mr Ian Smith</name>
            <isapetowner>true</isapetowner>
        <driver1>
    </driverdetails>
    <vehicledetails>
        <vehiclecode>53579303</vehiclecode>
    </vehicledetails>
</motorproposal>