Analysis on the application of XML in financial industry

xml| problem

　　Guidance-XML is becoming the de facto standard for data exchange with its open, self-describing, forward-compatible features, and extends its tentacles to different areas of the financial industry, although the road is not smooth and somewhat muddy.

XML, with its open, self-describing, and forward-compatible features, has become the de facto standard for data interchange and extends its tentacles to different areas of the financial industry, although the road is not smooth and somewhat muddy, but the application of XML in the financial industry is still moving forward.
Industry standards that are gradually approaching

Currently, several different XML formats have emerged for different financial applications. such as interactive Financial Exchange (IFX) and Open Financial Exchange (OFX) standards, they deal with consumers and other forms of micro banking business.

Financial Information EXchange (FIX) appears as a standard communication protocol for property transaction data. After joining the ISO 15022 XML workgroup, Swift has adopted XML as its primary presentation format and has transformed its historic data model into XML form. Financial Products Markup Language (Financial Product Markup Language, FpML) is used in financial derivative markets and is often used in complex negotiations. Extensible Business Reporting Language (extensible Business Reporting Language, XBRL), mainly for business reporting and data preparation and exchange.

None of these standards can cover all banking operations. The differences between accounting and auditing systems make these standards difficult to apply in the domestic financial sector. There is also a lack of specialized institutions and talents for financial data exchange to formulate appropriate national conditions, and has a certain authoritative standards, but these standards have important reference significance can not be ignored.

Over five miles.

The lure of XML has led many banks and financial firms to develop internal XML standards for data exchange and storage. The formulation of the mark, the enumeration of attribute values, the number of transaction elements and the subdivision of elements have also seriously impaired the standard meaning of XML. The use of different XML message specifications by different banks in the same field and the use of different XML message specifications between different systems within the same bank greatly weaken the openness of XML language.

At the same time, in the actual use of XML for financial data exchange to deal with the following five problems, after the five hurdle, XML will play a real strength.

　　1. DTDs and schemas

To illustrate the syntax rules of an XML glossary, you can use a document type definition description (DTD). DTDs use formal syntax to define the structure and allowable values of XML documents. By creating DTDs, the glossary can be formally and precisely defined, enabling the parser to use DTDs to validate the validity and integrity of the document instance. Unfortunately, the data type of the DTD does not appear to be exhaustive in its constraints on the XML file. For example, the account number and the applicant's name are described as #pcdata (strings). But the account number is an integer, and it may be a 32-bit long integer. Another regret is that the DTD uses a non-XML file to describe the XML file. The use of XML schemas can solve the above problems to some extent. An XML Schema is a well-formed XML file that provides a variety of data type definitions and allows you to extend, limit, and combine those definitions to create your own complex types. However, it is necessary to note that the XML Schema specification is developing.

As a bank's cross system application, using a DTD or XML schema can better represent and understand the XML document structure for Exchange, and instruct the structure and content errors in the XML document. However, the general custom XML message lacks the DTD or XML Schema definition, and the document rules are random and constantly modified. This may not be a problem in a system-internal exchange, but for data exchange across systems and across banks, there are differences in understanding and inefficiencies.

　　2. Length and performance

One of the main consequences of self interpretation is that XML documents are difficult to control in length. The display of tags and attributes greatly increases the length of the message. The increase of message length has two side effects: The success rate of message sending is reduced and the memory and CPU usage of parsing message increases. The message length is usually limited by using sockets or messaging middleware. With the increase of message length, the success rate of communication is significantly reduced, especially in WAN communication. In addition to parsing XML documents using DOM or sax, there is considerable memory and CPU resource footprint.

The general trading elements of financial transactions, especially after the integration of customer relationship management and comprehensive account information, send and return information significantly increased. A commonly used method is to compress and transmit the message, the general compression ratio can reach 30~50% in practical application. The other is the use of abbreviations, for example, the transaction _account _number written tranaccnum, can reduce the length of the message, to some extent to avoid people to focus too much attention on the mark and ignore the real content, of course, not too simple, Otherwise, the meaning of using XML language is lost. Defining some information as an XML attribute can also reduce the length of the document.

　　3. Memory Management

All XML parsers are basically grouped into two classes: a tree based interface, such as a Document Object model (DOM), an event-based interface, such as a simple XML API (SAX). DOM-type interfaces use a tree structure to randomly traverse and modify XML documents. But using this type of interface consumes more memory. When using XML to process a large amount of data exchange, the system will be stressed, and even a system crash occurs.

An event-based interface can be a good choice. It does not support random access to XML documents, but rather takes a sequential approach to access. Regardless of the size of the XML document, the amount of memory used is basically certain. At the same time, processor time is less expensive because no new objects are created at run time. However, programming with sax-type interfaces is more complex and does not have a forward reference to the document.

In practical applications, if you pay attention to ease of use, generally using the DOM interface, such as more attention to performance advantages, select the Sax type interface better. Of course, you can reduce the memory footprint of the DOM parse tree by reducing the number of nested layers of XML elements.

　　4. Size of Marker

The granularity of an element can always be confusing when it comes to making XML specifications. Does something come together as an element or as a separate element? For example, is the name divided into the first and last two elements to be labeled, or put together as an element? Personally feel that the guidelines on the definition of granularity is one: try to subdivide it. It is possible to support combinations of various forms only if the smaller the granularity of the subdivision is. Many other sources of information are derived from legacy systems, which, if swallowed, use their information formats to reduce the difficulty of data segmentation on the surface, but this can create significant barriers to data sharing and data consolidation.

　　5. Structured definition

Many times in order to improve the efficiency of parsing XML documents or shorten the length of documents, consciously avoid the use of multi-layer structured XML document definitions. Of course not that the XML document does not have a root node, but the hierarchy of the nodes is controlled at the 2 ~3 layer. This clearly violates the original intent of XML design. What is the difference between an XML document without a structure and a general exchange message? In fact, there is a hierarchy of data and information exchanged in large quantities.

In the financial field, the node hierarchy can be divided into two areas of business categories and business elements. The first is the field of business categories. The general transaction data contains the message header, customer basic information, account information, transaction-related information, such as a number of major components, under which it contains elements of business elements, such as account information in the field, including account number, account type, storage period, currency, book numbers, pen number, opening date and other related elements of business elements. Through these two levels of division, it is possible to explain the hierarchical structure of XML messages for Exchange. But the business element domain element can further divide the level to explain the related attribute.