Unlike tradition software simulators that have been developed to cater for specific situations, Frurion™ has been designed to be flexible and dynamic. The data dictionary services are the heart of the Frurion™ application suite. The various data dictionary editors that are supplied with the standard product allow the user to define new, and readjust existing, data elements and messages, dynamically, without the need for any software changes. The data dictionary adds a level of abstraction above the ISO-8583 or APACS metadata by use of an XML schema and this provides the same consistent design-time and run-time environment.

The advantage this gives, is that any ISO-8583 or APACS message structure, consisting of any number of data elements, can be defined and stored in the data dictionary by just using the supplied message editor. Data elements too, can be defined to any format the user requires, simply by using the supplied element editor.

Once these new definitions are saved, test data can be created according to the new definitions, and any existing test data is automatically realigned simply by using the supplied data editor. The simulators automatically adapt to the new definitions without the need for any software changes. Test data also adapts itself when a message structure changes: the data dictionary takes care of existing data values, requiring the user to only supply data values for new elements in the message.

The definitions contained within the data dictionary control the behaviour of the simulators and any associated test data. This simplifies the task of preparing for forthcoming Scheme compliance changes, as these changes can be created ahead of their implementation and test data can be prepared in readiness for when the host system is upgraded.

This flexibility allows the same, familiar interface to be used to test multiple variants of the messaging standard: even with multiple data dictionary definitions, the user is simply required to select the appropriate one for testing a particular host at any one time. For example, credit card definitions for one Scheme can be stored alongside debit card definitions for the same or an alternative Scheme – facilitating the testing of a host system (acquirer or issuer) that interfaces with many Schemes, for example.