Building with XML   Table of contents   Indexes   XML DTDs for Electronic Commerce and EDI
Harvey, Anna
 London 
 SGML Technologies Group 
 United Kingdom 
 		Anna Harvey
 Senior Consultant
SGML Technologies Group
 35 Piccadilly London  United Kingdom (W1V 9PB)
Email: mailto:anh@sgmltech.com Web site:http://www.sgmltech.com
 Biography
 Anna Harvey has worked with SGML and its daughter XML for ten years, originally for HarperCollins and several Thomson Group companies, but more recently with the SGML Technologies Group developing strategic systems for the financial services industries and the European Union budget.
 

The Insurance Industry in the United Kingdom

Insurance
 		 In the United Kingdom, the insurance industry is becoming polarized into large multi-product insurers who sell in all sectors (commercial, health, motor, life, assets, and re-insurance), and smaller companies which specialize in a particular niche of the market.
 This paper focuses on the life and pensions insurance market, which is going through considerable change, needing to respond to national legislation and to overseas entrants with dramatically different cost bases. The target is to remove £3 billion a year in costs from the market, with e-commerce the enabler. Life insurers currently spend millions of pounds each year distributing data to independent financial advisers (IFAs), largely via a handful of value-added service providers who charge for their consolidation service. Insurance companies believe that setting standards will foster new distribution channels and a more open market, and reduce costs significantly. The case study describes industry roles and gives a snapshot of emerging standards and the processes behind their development.
 The starting relationship of the parties is shown in the figure below.
 
 The product providers are the insurance companies, which define products and supply data defining them to the marketplace via service providers and IFAs. They carry out transactions for quotations, new business, commission, and policy servicing.
 Service providers aggregate product information from all insurers,add value to the insurers' information such as consistent presentation and navigation.
 IFAs interact with the individual customer, and provide face-to-face advice and sales. They carry out administration of customer details and data, and add information including news and related links.
 Large multi-product companies have organic growth supplemented by acquisition. They use multiple sales channels, both across different product areas and within a given product area, such as life insurance. Their market is highly competitive, with a need for rapid innovation. However, the large providers may be traditional in culture and in technology.
 The number of electronic commerce initiatives within the finance industry appears to be growing exponentially. As these initiatives develop, pressure is increasing to resolve technology differences between insurers and IFAs.
 

Role of the Standards Body

 Standards 
 		 In response to the technical issues raised by electronic commerce, Origo, a not-for-profit organization sponsored by the major insurers, is developing industry standards. Its mission is to build agreement and drive strategies to develop and implement widespread electronic commerce for all practical business purposes in the financial services market.
 Insurers who sponsor the standards body are joined in providing input to the standards-making process by the service providers and independent financial advisers. The nineteen sponsors represent 50 per cent of the United Kingdom life business and 90 per cent of the IFA market, which comprises 21,000 registered individuals.
 

Working Methods

 Typical working groups involve both shared and individual activities (those undertaken among participants and within participants' own organizations respectively). The emphasis of the project is on shared activities, so inter-organizational teams are the main vehicles for project work.
 Much of the work is carried out in meetings. Work-stream teams agree amongst themselves what attendance is required at meetings. Ideally each committed participant would be represented at all meetings. It is the responsibility of each committed participant who cannot be at a meeting to ensure that other attendees are briefed and can reflect his views. Organizations from the broader group of participants may be invited to contribute to meetings, at the discretion of those leading the activities addressed at the meeting.
 Participating organizations must ensure that those attending meetings:
 
  •  are qualified and have the authority to contribute on their behalf;
  •  have reviewed preliminary material, so they are up-to-speed on the topics to be dealt with at the meeting (this is particularly important for those joining the project or a series of meetings once it is in progress);
  •  have the authority to agree to points under discussion or have been briefed as to points they must refer back to others within the participating organizations;
  •  contribute constructively and are prepared to take actions to be progressed after the meeting;
  •  review minutes and respond within reasonable timescales, particularly if there are points they disagree with;
  •  attend throughout a series of meetings as necessary to provide continuity on behalf of the organization.
 

Establishing the Architecture

InternetArchitecture
 		 So that standards can work effectively, it is vital that the industry operates to a commonly agreed broad architectural framework which facilitates easy-to-use electronic processes, and achieves the desired efficient business solutions. Given the complexity of the marketplace, the diverse business interests, and the number of emerging technologies, the design and maintenance of this architecture will be complicated and politically charged. Origo and its sponsors developed the strategy of an Internet-based standard architecture, moving away from technology islands with individual links and extranets.
 This new architecture allows the groups to work together both in the immediate term, and to prepare for emerging technologies to be exploited in the future.
 Benefits of establishing this Internet-based model are that it:
 
  •  assigns responsibilities for each party to provide Internet-based services;
  •  highlights areas where standards are helpful;
  •  allows disparate Internet initiatives to be compared against the same baseline;
  •  provides a framework for decisions to be made with consideration for long-term solutions.
 The principle was also established to enable scaleable and non-proprietary systems to evolve.
 
 In the long-term, when new devices and sales channels are incorporated, the roadmap may be as illustrated above.
 

Developing Message Standards

Messages
 		 Implementation of standards means that transaction data needs preparing only once for use over multiple delivery systems. This will ultimately reduce paperwork, save time and effort, avoid repetitive input of data, and provide a quicker, more effective, and professional service to customers.
 Following the agreement of architectural principles, Origo was directed by its sponsors and board to develop a quotations message standard for the exchange of single company quotations between insurers and IFAs. The development of industry-standard messages forms a subset of industry standards activity, and their use allows trading partners to develop operational services in a common direction, secure in the knowledge that industry requirements are met, baselines have been established, and all changes are controlled.
 This quotations message standard is now in use and is under the control of the Origo standards management function to allow for the evolution and maintenance of the messages.
 

Project Teams

 A Quotations Project Team was set up in August 1998 with eighteen industry representatives from a number of companies, including insurers, service providers, and IFAs. This team was split into two subgroups, with specific responsibilities:
 
  •  Business Subgroup - Message Functional Guideline (MFG) containing business data content and rules for each message;
  •  Technical Subgroup – Recommendation on implementation formats to be supported by the Origo standard, and a Message Implementation Guideline (MIG) for each implementation format chosen.
 The term 'implementation format' is defined as the technique for structuring the data within a message, and is independent of the transmission method (eg X.400).
 The first task of the Technical Subgroup was to evaluate implementation formats for exchanging business data using Internet technology, and to recommend the implementation format for the quotations message standard.
 

Choice of XML

 XML 
 		 Implementation format options proposed for consideration by the Quotations Technical Subgroup were:
 
  •  XML (eXtensible Markup Language);
  •  EDIFACT (Electronic Data Interchange For Administration, Commerce and Transport);
  •  NPD (Name Pair Data);
  •  OFX (Open Financial Exchange);
  •  a proprietary standard.
 Several assumptions and constraints were behind the evaluation. One criterion was that the implementation format had to fit the architecture model, that is the selected format must be capable of delivery using Internet technology. It was assumed that the technology to support each of the implementation options considered would be available. How widely available this technology is has been assessed for each option. The exchange of the quotations messages must be on an interactive basis, and this capability was borne in mind when discussing each of the possible implementation methods. It was further assumed that generic requirements such as security, business controls, and auditability will be able to be satisfied by the implementation method, using either inherent or bespoke features.
 Pros and cons of XML were highlighted by the industry working group, making it the best option in comparison with other formats, but nonetheless with perceived risks.
 Strengths:
 
  •  XML is self-describing, so the format of the message is embedded and only need be sent the first time a message is exchanged;
  •  changes to messages would only need making once, so the time to implement amendments is short;
  •  XML supports the structuring of hierarchical data in an elegant and consistent manner;
  •  it was envisaged that XML would be independent of technical infrastructure and enabling software;
  •  search and information exchange can be automated;
  •  XML allows for flexibility of presentation of information between partners exchanging a message.
  •  Weaknesses:
  •  although XML is an inherent part of Internet Explorer, and potentially many other software offerings, it is not part of older browsers;
  •  it may be difficult to identify relevant operational applications, as XML is not yet widely used;
  •  XML messages are likely to carry a size overhead as they include data tags as well as the data itself;
  •  XML is a relatively new standard so the skills base is restricted (for all industries).
 

Standard Components

 The framework for the standards is that theMessage Functional Guideline (MFG ) provides detail of the business functionality, business rules, and business data content within the business functional area. TheMessage Implementation Guideline (MIG) specifies the structure and components of a message for a particular method of data exchange or implementation, XML in this case. These guideline documents are used in specifying traditional EDI methods.
 
 Inter-related Standards Components
 The development of message standards was based on the development of an Industry Standard Data Dictionary (ISDD)®, developed by the Business Subgroup whose brief was to establish the data dictionary, data model, and code lists. The working group also developed a naming convention for data elements and a list of standard abbreviations. The scope of the ISDD repository is all the standard messages, that is new business, commission, valuations and events, quotations, group enquiries, and bulk data download. Some of the messages within this scope had already been specified in other formats, and for easy transition and economy of effort existing analysis was re-used.
 On analysing the data identified across all messages, problems typical of any such rationalization were found such as inconsistency and duplication, different levels of detail, and unwieldy message representation.
 It was therefore decided to develop a rationalized and consistent ISDD design at the business functional level of detail. Data models help both to develop and then confirm the business content of a message, and are used both to build and review a message. An effective model provides the foundation for consistent business data element usage across the message set. This is reinforced if the data content of the ISDD is presented at the functional level rather than at implementation level, because the correspondence between message components and ISDD data elements is very close at the functional level.
 A related group of standard messages is in the process of being developed in a number of functional areas, including single company quotations, new business, and valuations and events.
 

DTD Issues

 DTDs, Document Type Definitions 
 		 The following characteristics were required of XML DTDs:
 
  •  to be available to all parties electronically;
  •  to adhere to version controls;
  •  to define valid XML elements for each message through content models;
  •  to allow for trading partner-specific features;
  •  to contain some validation rules which may be enforced by a standard parser;
  •  to define relationships between XML elements within the messages they support;
  •  to be easily maintainable;
  •  to be fragmented for reuse and conceptualization.
 

Modular Approach

 DTDs have been designed as a series of modules to aid understanding and reuse, with various aspects taken into consideration.
 

Business Area View

 In the short term at least, trading partners may not implement all functional areas within the XML-based message standards, and therefore use only certain parts of the DTD. The design uses a top-level DTD containing general and commonly used data, with data relating specifically to one of the functional areas being contained within a function-specific part of the DTD. These sub-DTDs are included as required by the parser software.
 

Product View

 For the quotations message standard, it was initially considered that each sub-product would be represented by a specific message within the DTD for maximum rigour. However, as many of the different products and sub-products have similar structures, and make use of many of the same elements, it was decided to use a looser generic DTD. The XML MIG contains the different message structures for various products, with a content matrix describing the data content of each of the sub-products. The XML representation of these uses attribute values within an XML element,
 
eg <product type="pension" subtype="epp">
 to emphasize relationships and maximize re-use.
 

Content View

 The data content of the quotations messages can be broken down into a number of reusable logical groups containing related data, such as:
 
  •  Common;
  •  Control;
  •  Party;
  •  Commission;
  •  Product
     
    •  Money in,
    •  Protection benefit,
    •  Investment,
    •  Money out,
    •  Existing policy,
    •  Illustration.
 The DTD consists of modules or entities for each of these logical groups.
 The quotations message standard also allows for 'trading-partner-specific' information to be contained within the structure of each message via entities allowing additional objects to be defined.
 

Attributes and Entities

 The Origo DTD and messages typically use attributes for restricting values to the entries in a particular code table, and for identifiers and administrative information such as version number, and also in cases where their use would add value and elegance to the structure of the business data.
 Entities are used to define modules of the DTD and to specify reusable consistent components such as global attribute types.
 

DTD Validation

 As much parsing validation as possible has been built into the DTD, but as a consequence of the generic message approach for the message standards the content models are relatively loose, limiting the valuation possible by parsing to:
 
  •  valid XML elements and attributes within the entire message;
  •  the structure of some groups, eg name and address, and product specific elements;
  •  code list validation.
 More detailed validation is needed at the application level, ideally in the client (IFA) layer. This could be either within each application or possibly within a tool invoked by applications compliant with the standards.
 Eventually, W3C work on XML Schemas is expected to provide a schema-based approach to capturing structure and allowed values, and may in due course supersede DTDs as the standard issued by Origo when suitable tools have evolved.
 

Data Model/DTD Relationships

Data model
 		 There is a natural relationship between the data structures contained within the XML DTD and the components of the ISDD logical data model, described in more detail below.
 

ISDD Entities

 The messages have been broken down into a number of logical groups or fragments as described above. Some of these correspond to entities within the data model, while others are specific to the physical exchange of messages. Some of these XML fragments may be represented as a combination of one or more entities within the data model. Using the more 'generic' fragments within the XML messages and DTD should simplify implementation of the message structures by trading partners, provides an accurate reflection of the purpose of the message, and assists reusability.
 

ISDD Attributes

 Where there is a match between attributes of an ISDD entity and the content (XML entities, elements, or attributes) of the equivalent fragments of the XML DTD, the relationship should be formally captured and maintained. Again, as for entities, there will be some components of the XML messages which cannot be matched directly with structures in the ISDD data model. XML elements defined are of two categories, small components which are widely reused, and coarser components describing concepts.
 Experience with existing XML applications shows that flatter structures can lead to incomprehensible data for complex instruments, while a component-based approach is more extensible. Hence there are intermediate-level XML elements with no one-to-one equivalent in the data model, being groupings of ISDD attributes defined for processing or conceptual purposes.
 The current XML standard (1.0) has no mechanism for representing a data type, and as a result this ISDD attribute information cannot be reflected within the XML DTD.
 

ISDD Relationships

 The XML DTD and the XML messages themselves are physical implementations of a business transaction and their structures reflect this. Nevertheless, there will be some cases where the relationships represented in the messages and DTD fit naturally against the structures of the ISDD data model. It is impossible to formalize cases where this 'fit' will occur; however, where it does exist, it will be documented and maintained. Further work on the data model is underway to develop physical views of the data to achieve consistency.
 

New Business Project

 A related project was launched by the industry to find ways to implement e-commerce, Origo again being involved in identifying potential areas for standardization and managing them for the industry, as well as facilitating the entire project. It was felt that there was enormous opportunity for improvement in the e-commerce handling of new business, which is currently paper-based, in many areas. Several targets have been set.
 Firstly, reduction in time to submit and process an application for a new policy is foreseen, as it would be possible to maximize pre-population of the proposal form from existing data and include supplementary questions as part of the data capture process. Then there can be improvement in the quality and accuracy of applications submitted, through the use of validation routines within the electronic proposal. Here the number of requests for further information to IFAs is minimized as well as unnecessary IFA client visits. Moreover, there could be a reduction in communications time and cost where, for example, changes are requested, or additional information is required, with a reduced risk of lapses (customer taking business elsewhere) and elimination of non-value-added activities.
 E-commerce could support process development for signature-free processing, electronic money transmission and settlement, growth in business volumes, and the rapid definition of new products.
 To enable service improvements and cost-savings to all participants, a business framework was agreed to underpin the e-commerce technology. This did not change individual commercial relationships between participants, but provided the context for introducing new technology.
 A parallel technology stream had the brief of implementing software for IFAs to prepare new business proposals on behalf of their customers, integrated with the IFAs own systems. This would be coupled with software for the insurers to distribute product definitions and accept applications. Needless to say there is a requirement for communications facilities. These developments are to be based on the industry standards and architecture and with the following requirements.
 For IFAs:
 
  •  standard look-and-feel of display across insurers;
  •  dynamic, context-sensitive data capture;
  •  data integration across processes and maximum pre-population;
  •  to be able to work off-line up to submission of the proposal;
  •  to be able to work online;
  •  to be able to complete an application partially and pick it up later;
  •  printing of applications only when requested;
  •  technology platform and vendor independence;
  •  improved quality of data capture at the source of capture;
  •  request for data capture to be minimized;
  •  minimize time to issue policy documents.
 For insurers:
 
  •  product independence (same solution for all products);
  •  channel independence (same solution for all channels);
  •  fast route to market (minimize program code changes);
  •  standard solution for all service suppliers/software houses.
 

Process-Driven Architecture Framework

 To apply the standard architecture for new business e-commerce, the processes involved were identified. The way they interact is shown in the figure below.
 
 New Business Application Processes
 Using the elementary processes in the process model together with the requirements, the following architecture was developed. The architecture does not imply a particular technical solution or environment, but defines the key components to be developed. To help the industry implement new methods quickly, Origo was asked to identify possibilities for further standards to be used across the industry.
 
 

Standards Within the Architecture

Data capture
 		 The working groups identified the functional requirements of the Product Application Component (PAC) and PAC handler components of this architecture. These components are concerned with the data capture process carried out by IFAs, and the processing of data to generate messages. It was agreed that standards could be developed and managed by Origo to provide a generic basis for these components, with limited customization by IFAs and service providers to carry out their own particular role in adding value and consolidation. The working groups have now agreed requirements for a syntax capable of providing a generic PAC which can be customized in its presentation for screen and paper output. This will be based around XML and related standards. Rather than defining a syntax from scratch, various software suppliers to the industry have offered to cooperate by sharing their proven approaches to this problem, so that Origo can quickly offer a best-of-breed tool set as a standard for the industry. The next steps will be to implement these solutions for a simple product and a small number of participants, moving on to a larger group and a diversity of products.
 

Conclusions

 Origo has made considerable progress in its role of developing industry standards and facilitating the uptake of electronic commerce in the financial services market. This has been possible thanks to the active and generous participation of a range of parties throughout the industry, who share the vision of the benefits of e-commerce across the industry and have worked together for shared benefits.
 Historically, the industry has been slow in adopting standard e-commerce solutions, with piecemeal initiatives springing up. Coherent progress has been improved by the use of the Internet and XML as the basis of standards. Furthermore, there has been enthusiasm and commitment from participants who are already using technology-based solutions and are ready to exploit standards as soon as they become available.
 As well as dealing with technology issues, Origo has been successful in taking a wide business view, which prepares the industry for the future and brings benefit to all parties and their customers.
 

Acknowledgements

 I should like to acknowledge the work carried out by the team of experts at Origo and the technical team from GEIS.
Building with XML   Table of contents   Indexes   XML DTDs for Electronic Commerce and EDI