This project is read-only.

Mysim9: Financial transactions middleware simulator

Personalized, customizable middleware simulator, works as a middleware or endpoint.

Keywords: Phoenix, MiSys, FlexCube, middleware, controller, switch, CRM, IVR



While interacting with a middleware there a need of a highly customizable simulator that should work handy, for the developers as well as testers.


This application is primarily targeted towards the integration of banking middleware software where several software talk to each other to process a financial transaction. For instance, middleware switch, HSM, core banking host, CRM, IVR, etc. This simulator is precisely based upon ISO8583’s financial transaction messages. It also works with customized messages formats.

 MySim9 Simulator, IVR, Core Banking, Host, Channel, ATM, CDM, PIN, Transaction, Controller, Testing


  • Shall work as a client

o   Multiple client-instances shall also be supported

  • Shall work as a server

o   Shall connect multiple client at a time

o   Shall respond to each client accordingly

  • Shall provide a user interface to configure the format.
  • Shall prepare requests and responses according to the defined message format.


MySim9 simulates any host that has a message format, and talks on TCP; be it middleware, CRM, IVR, SMS, etc. During development/testing phase of Middleware a need to code their own simulator to test the developed functionality is being followed, as convention it seems. Every project require either to develop a new simulator from scratch or modify the existing simulator code.


When to use?

Consider a scenario where you are developing Biztalk triggers and you need the message request to be sent to the host again and again from, for instance, CRM; So that you may test/debug/update the code. In that case all you need to do is to configure the xml file, called Simulator file, and hit the start button of MySim9 simulator; rest is going to take care by MySim9.

 Similarly, while MS Dynamics CRM is going through the dev/testing phase, usually a developer/tester requires a Middleware to test with; to be online and respond to all the requests sent by CRM. So, CRM will need to configure the simulator and start the process.

 This would act as a well defined custom message format between two or multiple parties; for instance, an ATM Controller and multiple Middleware connecting to it.

 Also, an IT project manager, of a Bank probably, can have it handy to test or verify the message format.

 A sample Base24 simulator configuration file sample is displayed in this document.

 Schema Design

   <?xml version="1.0" encoding="utf-16" ?>

- <xs:schema xmlns:msdata="urn:schemas-microsoft-com:xml-msdata" xmlns:b="" id="MySimulations" xmlns:xs="">

- <xs:element name="Field" nillable="true">

- <xs:complexType>

- <xs:simpleContent msdata:ColumnName="Field_Text" msdata:Ordinal="6">

- <xs:extension base="xs:string">

  <xs:attribute name="Name" type="xs:string" />

  <xs:attribute name="DataType" type="xs:string" />

  <xs:attribute name="Length" type="xs:string" />

  <xs:attribute name="AutoPad" type="xs:string" />

  <xs:attribute name="PadRight" type="xs:string" />

  <xs:attribute name="PadChar" type="xs:string" />





- <xs:element msdata:IsDataSet="true" msdata:UseCurrentLocale="true" name="MySimulations">

- <xs:complexType>

- <xs:choice minOccurs="0" maxOccurs="unbounded">

  <xs:element ref="Field" />

- <xs:element name="Simulator">

- <xs:complexType>

- <xs:sequence>

- <xs:element minOccurs="1" maxOccurs="1" name="Header">

- <xs:complexType>

- <xs:sequence>

  <xs:element minOccurs="2" maxOccurs="unbounded" ref="Field" />




- <xs:element minOccurs="0" maxOccurs="unbounded" name="Transaction">

- <xs:complexType>

- <xs:sequence>

- <xs:element minOccurs="0" maxOccurs="unbounded" name="Request">

- <xs:complexType>

- <xs:sequence>

  <xs:element minOccurs="0" maxOccurs="unbounded" ref="Field" />




- <xs:element minOccurs="0" maxOccurs="unbounded" name="Response">

- <xs:complexType>

- <xs:sequence>

  <xs:element minOccurs="0" maxOccurs="unbounded" ref="Field" />





  <xs:attribute name="Code" type="xs:string" />

  <xs:attribute name="Name" type="xs:string" />




  <xs:attribute name="Name" type="xs:string" />

  <xs:attribute name="server" type="xs:string" />

  <xs:attribute name="IP" type="xs:string" />

  <xs:attribute name="Port" type="xs:string" />

  <xs:attribute name="MetaLength" type="xs:string" />

  <xs:attribute name="MetaType" type="xs:string" />

  <xs:attribute name="Separator" type="xs:string" />

  <xs:attribute name="Delimited" type="xs:string" />

  <xs:attribute name="RequestCode" type="xs:string" />

  <xs:attribute name="ResponseCode" type="xs:string" />









Sample Configuration File

 <?xml version="1.0" encoding="utf-8"?>


  <Simulator Name="IVR" server="false" IP="" Port="3000" MetaLength="4" MetaType="Meta.Txt" Separator="|" Delimited="true" RequestCode="0200" ResponseCode="0210">

    <!--  Message Header -->


      <Field Name="Message Type" DataType ="Type.String" Length="4" AutoPad="true" PadRight ="true" PadChar ="0" >0200</Field>

      <Field Name="Transaction Code" DataType ="Type.String" Length="3" AutoPad="true" PadRight ="true" PadChar ="0" >000</Field>

      <!--  Transmission Date and time created by the IVR and it will be generated for each call -->

      <Field Name="Transmission Date and Time" DataType ="Type.Date" Length="10" AutoPad="true" PadRight ="true" PadChar ="0" >ddMMhhmmss</Field>

      <!--  6 Digit Random Number generated by delivery channel -->

      <Field Name="Stan" DataType ="Type.AutoNumber" Length="6" AutoPad="true" PadRight ="true" PadChar ="0" >5555</Field>

      <Field Name="Customer Identification" DataType ="Type.String" Length="13" AutoPad="true" PadRight ="true" PadChar ="0" >NIC</Field>

      <Field Name="Message Protocol" DataType ="Type.String" Length="2" AutoPad="true" PadRight ="true" PadChar ="0" >01</Field>


    <!--  Message Header End  -->


    <!--  Transaction 1  -->

    <Transaction Code="02" Name="TPIN Validation ">


        <Field Name="TPIN" DataType ="Type.String" Length="16" AutoPad="true" PadRight ="true" PadChar ="0" >DESEncryptedTPIN</Field>



        <Field Name="ResponseCode" DataType ="Type.Number" Length="3" AutoPad="true" PadRight ="true" PadChar ="0" >000</Field>



    <!--  End Transaction 1  -->


    <!--  Transaction 2-->

    <Transaction Code="50" Name="ATM PIN Validation">


        <Field Name="NewPin" DataType ="Type.String" Length="16" AutoPad="false" PadRight ="true" PadChar ="0" >DESEncryptedTPIN</Field>



        <Field Name="ResponseCode" DataType ="Type.Number" Length="3" AutoPad="true" PadRight ="true" PadChar ="0" >000</Field>



    <!--  End Transaction 2  -->


    <!--  Some more transactions  -->

    <!--  End some more transactions  -->




 User Interface

 MySim9 Simulator, IVR, Core Banking, Host, Channel, ATM, CDM, PIN, Transaction, Controller, Testing

FIG 1: MySim9 Simulator





o   Generate Sample

o   Edit

o   Reload

o   Help, this help

o   Maintain log file

o   Browse data file button

o   List of simulations available

o   List of Transactions available for a simulation

o   Start button

o   Send button



 Generate Sample

Generates sample simulator file, contains specific simulations.

 FIG 1.1: Generate sample xml option


  1. Edit

Edits the simulator file (xml) file, in the default edit(for instance, notepad.exe)


  1. Reload

Reloads all the transactions from simulator file


  1. Help

Provides this help file.


  1. Maintain log file

Maintains a log file that contains the simulator status/details.


  1. Browse data file button

Browse button provides a window to select the simulator file (.xml)


  1. List of simulations available

Simulations list box provides list the of simulations available in the simulator file. By default top most simulator is selected, when you click the reload button


  1. List of Transactions available for a simulation

Transactions list box provides the list of transactions in the selected simulator.


  1. Start button

In case of client, it starts trying to connect to server; In case of server, it starts the listening process.


  1. Send button

Sends the text to the selected displayed on the complete message text box.

    1. In case of server, it sends the message to all of the clients
    2. In case of client, it sends the message to server.



How to use – step wise


  1. Double click to run the application
    1. Prerequisites,

                                                    i.     MySim9.exe must be having the simulator file (.xml) with it in the same directory

                                                  ii.     MySim9.exe must be having theNetworker.Dll in the same directory.

  1. Choose the browse button to select the a valid simulator file (.xml)
  2. Click reload button to load the contents of the xml file
  3. Click on start button to run the process.



FIG 2: Simulators working as server/client.



How to configure simulator file 


Simulators are as follows:



<Simulator = IVR>


Header related fields


<Transaction Name = “Balance Inquiry” Code = “100”>

Fields/values in a transaction


<Transaction Name = “Customer Demographics”> …</Transaction>



<Simulator = CRM>



<Simulator = Phoenix>



<Simulator = SomeHost>





Simulator Attributes

  1. Simulator name

Name of the simulator


  1. Server (True | False)

True means it’s a server.


  1. IP

IP address


  1. Port



  1. Meta Length

Length of message that is padded on the top of message. For instance 4 bytes ASCII or 2 bytes binary.


  1. Meta Type

Type of coding, supports binary, ASCII, and Hexa.


Supported types are:

o   Meta.Txt, converts to text/ascii

o   Meta.Bin, converts to binary

o   Meta.Hex, converts to hexadecimal

o   Meta.None


7. Data Format Types

Converts the meta length into text, binary, hexa and octal formats:


1.     Format.Txt

Converts the data in plain text format; basically doesn’t change the data.

2.     Format.Bin

Converts the data in binary format

3.     Format.Hex

Converts the data in hex format

4.     Format.Oct

Converts the data in octal format



  1. Separator

Separator to be defined in between the message; any single character. Can contain multiple characters too. Example of sample separator is comma sign (,), pipe sign (|), hyphen (-), etc.


  1. Delimited

If true, means concat message without separator.


  1. Request code

Request code; for instance the ISO8583 financial transaction request code is 0200


  1. Response code

Response code; for instance the ISO8583 financial transaction response code, 0210



Header Element Attributes

  1. Name

Name of the transaction


  1. ExtractFromRequest (True | False)

Extracts this field from request message to prepare a response.


  1. Data type (Type.String |

Type of data being provided

Following data types are supported in this attribute.

  •  Works for 8(yyyyMMdd) and 14(yyyyMMddhhmmss) and the formatting defined as the field value. For instance, <field1>mmddyyyy</field1>
  •  Works for 6(hhmmss)
  •  Adds the number
  •  Creates an auto number of the provided length. For instance,

  <Field Name="ISO Literal" ExtractFromRequest="false" DataType="Type.AutoNumber" Length="2" AutoPad="true" PadRight="true" PadChar="0">ISO</Field>


  •  Text based data
  1. Length: Length of field
  1. AutoPad:Pads automatically depending upon the length of the field
  1. PadRight: If false then pad left, otherwise pads right
  1. PadChar: Char to be padded with. For instance,

  <Field Name="ResponseCode" ExtractFromRequest="false" DataType="Type.Number" Length="3" AutoPad="true" PadRight="true" PadChar="0">000</Field>


  1. Field value: Value of the field.

Transaction Element


Transaction Element & Attributes


  1. Name

Name of transaction.


  1. Code

Transaction code that the transaction is uniquely identified with.


For instance,

<Transaction Code="BH0100" Name="Balance Inquiry">



Request element

Contains the fields to sent as a transaction request.


Response element

Contains field elements to be sent as a transaction response.

For instance,

<Field Name="NewPin" ExtractFromRequest="false" DataType="Type.String" Length="16" AutoPad="false" PadRight="true" PadChar="0">DESEncryptedTPIN</Field>





  1. The name of transaction code field in the header attribute, must be “Transaction Code”, otherwise system will behave abnormally.



Known Issues & Workarounds






No schema validation upon selecting the xml file

Workaround: Use specified format, for now


Can’t handle linear talking sessions, for instance, IVR requests middleware requests to ATM switch requests to HOST and then HOST responds to ATM switch responds to middleware responds to IVR.

Workaround: Future development, volunteer help


Button text doesn’t change when in client mode, when the client is forcefully stopped.


Workaround: Restart app.


Program will behave abnormally because no cross validation is being performed. For instance, if the transaction code length defined in Header is 3, and then the actual transaction code has 2 digits.

Use valid values



Server sending response message to all of the connected clients

Not so good solution, but for now use one client at a time.



Application doesn’t respond with a formatted message in case the requested message format is without separator. Works with separator and doesn’t work without separator.

Use delimiter in message formats.



Binary meta type doesn’t work

Use Ascii with 4 or more bytes


Hex meta type doesn’t work

Use binary or Ascii


Doesn’t work as a server, for instance it wont work in case a client (IVR for instance) requires static header fields in response message. For instance, IVR requires the exact STAN that was sent in the request message. At this moment, the response message creates a brand new STAN.

Run the simulator as client application, and always send requests.









Updates and Additions





Disabled the first row of message list box, so that user may not be able to select the header message.


Tooltips help added to the user interface.


Non printable characters now identifiable by a question mark (?).


Added log file functionality.





Change Requests




Requested by


Attribute can be added in all of the fields that would tell the parser whether to pull the value from request message or not. For instance for IVR Stan field, if ExtractFromRequest is true, then the parser would extract that value from the corresponding request message field.

Muhammed (IVR).


Simulator should send the data in hex upon request.

Kamran H. Khan.






Enhancement Areas





Add complete ISO8583 message base (including network messages/


Support all versions, ISO 8583-1-1987, ISO 8583-2-1993, ISO 8583-3-2003


Support all origins, Acquirer, Acquirer Repeat, Issuer, Issuer Repeat, Other, Other Repeat.


Support all functions, Request, Response, Advice, Advice Response, Notification, Response Acknowledgement, and Negative Acknowledgement.


And support all classes/types of messages, Authorization, Reserved by ISO, Fee Collection, Administrative, File Actions, Financial, Reversal, Reconciliation, and Network Management.




Last edited May 27, 2015 at 6:36 PM by kkhan, version 6