12.3. Mortgage domain mapping

Based on the article ‘SIVI AFS nu ook geschikt voor modellering hypotheekdomein’ (in SIVI AFS Magazine December 2022).

Introduction

With the SIVI All Finance Standard (SIVI AFS), it is possible to model the first facets of the mortgage domain. This is the result of the mapping SIVI is developing from HDN (Mortgage Data Network) to SIVI AFS / AFD 2.0. Indeed, SIVI’s agenda, in developing AFD 2.0, is to be able to support the capture of the complete customer record at the data level. This chapter describes how to fill this in for the HDN AX message, and the technical creation and components of this mapping.

The mapping of the AX message is the first step in a series of mappings SIVI is developing between the various HDN messages and AFD 2.0. HDN has a number of message types used for mortgage application and management processes. The message type for an offer request, AX, is the most comprehensive of these and the first we have translated to SIVI AFS / AFD 2.0.

The HDN AX message supports a very diverse set of data elements that cover all aspects of a request. This includes the parties involved, the property and the financial aspects related to the request. This means that this specification contains many data types, attributes and enumerations that are in a complex hierarchical structure: the data model. This structure is necessary to indicate which data is related to each other and how often elements can occur. For example: a request contains more than one mortgagor and for each mortgagor different details are important for the request.

From HDN AX message to loanStructure in SIVI AFS

The AFD 2.0 mapping makes it possible to convert any AX message, with all data elements being part of that message, into AFD 2.0 entities, attributes and code lists in an AFD structure: the loanStructure. This mapping takes into account the relationships of the original data model, so that no information is lost.

The underlying data model of the AX message is very comprehensive. In addition to mapping elements, there is also a transformation of the structure. The process is split up into a number of steps (see box). The mapping has been extensively tested for correctness and completeness.

AFD has supported the mortgage domain for many years. Therefore, it was possible to quickly map the vast majority of elements in the HDN AX message to existing entities, attributes and code lists in AFD 2.0. If necessary, SIVI made additions to AFD 2.0 to allow complete mapping of all HDN elements.

AFD 2.0 perfectly fit for data storage in the mortgage domain

The AFD 2.0 mapping for the HDN AX message supports the complete conversion of an AX message to AFD 2.0. Both the structure of the HDN message and all HDN elements that appear in the message (data types, attributes and enumerations) are converted to entities, entity types, attributes and codelists in the SIVI AFS loanStructure. The mapping HDN AX – AFD 2.0 shows that AFD 2.0 is perfectly fit for registration of data within the financial domain.

The mapping is quite complicated: the specification of an AX message contains more than 60 complex types (for elements that group data), which in total contain more than 600 data elements (attributes). The specification also contains a large number of enumerations: each enumeration describes the possible values that a certain attribute can have, comparable to code lists in the AFD. The challenge is not just to convert this to AFD 2.0, completely and flawlessly, but also to arrange it in such a way that future changes to the schema can be handled easily.

Approach

If conversion of the source message to an AFD 2.0 message is required, it is necessary to convert both the structure of the source message and all data elements to AFD 2.0 entities, attributes and code lists. But it is not necessary to map the structure at the same time as the data elements. The underlying reason is that if the structure already satisfies the desired end result, we can do the mapping of the data elements through a general function. This function uses a number of lists that describe the relationship between source elements and AFD 2.0 elements. This allows us to process all elements in the same way instead of modeling each element separately in MapForce. This is more efficient, more robust and avoids errors.

In order to convert the HDN message to a SIVI AFS structure, we first derived a schema of the new structure from the original source schema. We do this with the schema editor Altova XMLSpy, but this can also be done with a free text editor such as notepad++.

Implementation of the mapping in MapForce

The first step of implementation is to define structure changes. When implementing a mapping in MapForce, one specifies structure changes between the source schema and the new schema, with a connection for each element. MapForce then automatically connects the underlying elements. This makes it relatively easy to implement this type of structure change.

The second step of the mapping is to convert the names and values of all elements in a source message to AFD 2.0 entities, entityTypes, attributes and codelists. The basis of this step is a recursive function (within MapForce) that uses generic inputs and outputs. To control this function, we use the diagram from the previous step. During recursion, the software converts all the names and values of the elements in the source message.

The major advantage of the split into a mapping for structure and a mapping for elements, is that the element part is generic for all types of HDN messages and can basically use the same lists (containing all elements of all message types at the same time): this also guarantees consistency of the mapping for the different message types. Because each message type in HDN has a different schema and therefore a different structure, a specific conversion is used for the structure change of each message type though.

The two-step conversion of an HDN XML message ultimately produces a SIVI AFS-compliant message in JSON. In addition to interactively mapping a source message, MapForce also generates code for the implemented mapping so that other software – such as the SIVI mapping API – can make use of the mapping.

Generic process steps for reusability

Wherever possible, we have automated implementation steps. For every new HDN message, we have to create a mapping file, a SIVI AFS structure and an implementation of the structure conversion once. But we can reuse all other steps in the process. This is also an advantage when one of the message types gets a schema update. In that case, we can easily check the location of the new elements and changes in the data model and adjust the implementation where necessary.

The mapping of HDN AX shows that it is possible to convert complex data models to SIVI AFS / AFD 2.0 that are complete, auditable and maintainable. It once again demonstrates the broad applicability of SIVI AFS in the financial domain, including therefore the mortgage domain.