DESC:Field of the invention:

The present invention generally relates to financial transactions and more particularly, to a system and a method for encoding the retail and banking transactions of an entity.

Background of the invention:

Normally, in the financial retail payment transaction domain, monetary transactions take place between a merchant and a consumer, between a sender and a beneficiary or between two account entities in a system. Here, every payment transaction follows a global standard specification as it travels from the point of origin i.e. place of demand - where goods or services are required to the point of destination i.e. place of supply -where resources/funds are available.

Financial transactions have moved from paper based to electronic many decades ago. To facilitate global interoperability, international organization for standardization has issued a guideline specification document stating the transaction format for the electronic transactions. ISO8583 is one such interchange message specification for card-originated messages which are exchanged between acquirers and issuers. It specifies message structure, format and content, data elements and values for data elements.

The transaction format is standardised with these specifications and helps in interchange and interoperability. The format consists of data elements required for the authentication and authorization of the payer and the payee to complete the financial transaction between the two parties. The data elements consist of information like the date of the transaction, amount of the transaction, the payer details, payee details and several hundred such attributes about the transaction. The values in data elements are stored in the form of alphanumeric data in systems and databases.

Figure 1 shows a flow diagram of an electronic transaction in accordance with the prior art. Here, consumers perform various electronic transactions like making payments to merchants for goods or services, withdrawing cash on an ATM or renewing a subscription on a mobile app etc. Consumers initiate a transaction by using any one of card data input methods like swiping magnetic stripe of the card, by dipping the contact chip present on the card, by tapping the card on contactless reader, by entering card details manually on a website, by storing card details in a database etc. and using the details to initiate a transaction. The merchants or banks, providing goods or services to consumers, have various ways to allow consumers perform electronic transactions such as accept a card on a Point of Sale (POS) machine or accept a card to withdraw cash at an Automated Teller Machine (ATM) or allow consumers to provide their payment credentials on a E-commerce Website to allow remote secure commerce or allow consumers to transact on their mobile phone via an app etc. The merchants then accept consumer/cardholder payment instruments such as cards, mobiles, smart devices to authenticate the consumer. In this case, the acquirers are the banks who provide the banking facilities to merchants and provide settlement services to merchants. Acquires use hardware and software such as Point of Sale (POS) switch which connects the POS devices using a network and authenticate the consumer, ATM switch which connects all ATMs to bank’s systems for allowing banking services on the ATM, a payment gateway which securely facilitates transactions on an internet and a mobile banking server which communicates with a mobile app residing on consumer’s mobile and uses mobile features to provide mobile banking services.
Acquirers authenticate their merchant and forward the transaction to appropriate payment network. Payment networks are the aggregator settlement entities which connect acquires and issuers to facilitate message exchange between them and also carry out clearing and settlement process to move funds. Network forwards the transaction to appropriate issuer using identifiers in the transaction data. Issuers are the consumer’s banking partners who authorize the electronic transaction after performing appropriate authentication and authorization checks.

There are several data elements in the specifications which carry attributes about the physical situation in which transaction takes place. These data elements are heterogeneous in nature e.g. amounts, date and time, factors, IP addresses, device IDs, geo-location coordinates and like. Such heterogeneous data requires huge amount of data engineering effort to bring it to a state so that standard machine learning algorithms can be applied to it. Moreover, it is also resource intensive in terms of the processing power and memory required when it comes to training a machine.

In order to apply machine learning to the transaction data, existing processes used for training the model on transaction data are limited to using the numeric/alphanumeric data points and involves non-image based set of algorithms to train the machines. Transaction data being heterogeneous in nature, results in exploding the machine learning parameters multi-fold in case of neural networks or deep neural networks, requires servers and systems with high processing capability. The data being alphanumeric in nature restricts the algorithms that can be used for training. Eventually machine learning algorithms try to identify patterns, which can be done in much more efficient way in an image processing algorithm, provided we transform the transaction data in the form of an image. Further, it would be easier for business operations staff to understand and consume image based data, than alphanumeric data for manual anomaly detection.

Accordingly, there exists need to provide a system and a method for encoding the financial transactions that overcomes the above mentioned drawbacks of the prior art techniques.

Objects of the invention:
An object of the present invention is to encode the financial data so that it can be processed in a reduced cost and also results in reduced effort required for data engineering and modeling.

Another object of the present invention is to enable the financial institutions to create a behavioral model for the transacting entity and use the model to score a future transaction done by the entity as the transactions takes place in real-time.

Summary of the invention:

Accordingly, the present invention provides a system for encoding the financial transactions. The financial transactions, for example the retail payment transactions, are facilitated by the system using a point of origination device such as sale/interaction device connected to a router, an acquiring switch server, a payment network and an issuing switch server. The system comprises a transaction receiver module, a parser module, a normalizer module, a position mapper module, a channel mapper module, an image encoder module, a mapping dictionary module, an update module, a store transaction module, a transaction images database and an image definition module.

The transaction receiver module is embedded in the issuing switch server. The transaction receiver module receives a transaction and performs decoding of transaction message received from a source. The transaction receiver module may receive the transactions in any one of real-time or batch/bulk mode. The parser module is embedded in the issuing switch server and operably connected to the transaction receiver module for receiving transaction therefrom. The parser module breaks the transaction message into individual data elements using specification definitions. The normalizer module includes a predefined normalized value for each data element stored therein. The normalizer module stores the mapping of data element along with valid values of the data element, normalization technique to be used to normalize the data and the final normalized value against each value in the data element. The position mapper module stores mapping between data element number and the corresponding x and y coordinate in the image. The channel mapper module stores definition of data type to channel mapping and definition of each data element and attributes thereof. The image definition module stores the size of the image generated by the image encoder module.

The image encoder module takes inputs from the parser module, the normalizer module, the position mapper module, the image definition module and the channel mapper module to create an image. The mapping dictionary module is operably connected to the image encoder module and stores the mapping dictionaries of various transaction data elements. Specifically, the mapping dictionary module stores the mapping dictionaries of various transaction data elements with details such as field number, field value, field normalized value and pixel position in x and y coordinates. The mapping dictionary module includes a data pre-processor module, a data-cleaner module and a position lookup module embedded therein. The data pre-processor module and the data-cleaner module identify the data points present in the transaction specification and map them to the field numbers. The update module is operably connected to the image encoder module for updating mapping tables with any new fields or new data values in an existing field received in the transaction. The image definition module stores the size i.e. length and width of the image which will be generated as output by the image encoder module. The store transaction module is operably connected to the image encoder module for storing an output of the encoded transaction into the transaction images database. After all the pixel values for all data points in the transaction are assigned using the mapping dictionaries, the image encoder module forms an image of a pre-defined size and plot the pixel at the pre-defined location in the image to form a final image of the transaction.

In another aspect, the present invention provides a method for encoding the financial transactions.
Brief description of the drawings:

The objects and advantages of the present invention will become apparent when the disclosure is read in conjunction with the following figures, wherein
Figure 1 shows a flow diagram of an electronic transaction, in accordance with the prior art;

Figure 2 shows a block diagram of a system for encoding the financial transactions, in accordance with the present invention;

Figure 3 is a block diagram of a transaction flow showing components of the system of figure 2 embedded in hardware components, in accordance with the present invention;

Figure 4a shows an exemplary illustration of a single transaction encoding, in accordance with the present invention;

Figure 4b shows an exemplary illustration of bulk transaction encoding, in accordance with the present invention;

Figures 5a- 5d show flow diagrams of channel setup for creating an image, in accordance with the present invention; and

Figure 6 shows a flowchart of a method for encoding the financial transactions, in accordance with the present invention.

Detailed description of the invention:

The foregoing objects of the invention are accomplished, and the problems and shortcomings associated with prior art techniques and approaches are overcome by the present invention described in the present embodiments.
The present invention provides a system and a method for encoding the financial transactions in the form of images. The images are formed by using an encoding standard that maps the transaction data elements to pixel values in the image. This image encoding facilitates faster processing of this transaction data by applying advancements in image processing hardware and software and allows machine learning using image processing algorithms on transaction data.

This present invention is illustrated with reference to the accompanying drawings, throughout which reference numbers indicate corresponding parts in the various figures. These reference numbers are shown in bracket in the following description.

Referring to figures 2-3, a system (150) for encoding the financial transactions in accordance with the present invention is shown. The system (150) facilitates encoding of financial transactions, specifically electronic retail payment transactions, using a point of origination device such as sale/interaction device connected to a router (160), an acquiring switch server (170), a payment network (180) and an issuing switch server (190) as shown in figure 2.

The system (150) comprises a transaction receiver module (10), a parser module (20), a normalizer module (30), a position mapper module (40), a channel mapper module (50), an image encoder module (60), a mapping dictionary module (70), an update module (80), a store transaction module (90), a transaction images database (100) and an image definition module (110).

The transaction receiver module (10) is embedded in the issuing switch server (190) and performs basic checks of the transactions like message/file format, naming convention and stores the data in a standard format. The transaction receiver module (10) receives the transactions in any one of real-time or batch/bulk mode. Figures 4a and 4b show exemplary illustrations of single and bulk transaction encoding respectively. Specifically, the real-time transactions which may be received via TCP/IP or other real-time messaging protocols and the batch/bulk transactions which may be received via file transfer protocol such as secure copy protocol (SCP), to a specified folder on a server. However, it is understood here that the transaction receiver module (10) may receive transaction using any other protocol in other alternative embodiments of the present invention. The transaction receiver module (10) also performs decoding/decrypting of the transaction message received from a source.

The parser module (20) is embedded in the issuing switch server (190) and operably connected to the transaction receiver module (10). The parser module (20) receives a new transaction from the transaction receiver module (10) and refers to the stored transaction specification to understand the parsing logic to be applied and provides parsed data elements received in the transaction. The parser module (20) breaks the transaction message into individual data elements using specification definitions. For example, if we assume that following string of alpha-numeric characters represent a transaction:
01005123456789012340000005999320000356ABC JEWELLERS/411009/MHIN
The parser module (20) breaks the transaction as:
Message Type=0100
Card Number =512345678901234
Processing Code=000000
Merchant Category Code=5999
Transaction Amount=320000
Transaction Currency Code=356
Merchant name and address= ABC JEWELLERS/411009/MHIN

The normalizer module (30) is operably connected to the image encoder module (60). The normalizer module (30) includes a predefined normalized value for each data element value stored therein. This is done as an offline exercise to identify possible values which can be received in a data element and create a normalized value for each of it. Specifically, the normalizer module (30) stores the mapping of data element along with valid values of the data element, normalization technique to be used to normalize the data and the final normalized value against each value in a data element. For example, merchant category code is a data element in the transaction and assuming it has 5 valid values as an example: 5999, 6011, 0742, 7493, and 3999. The normalizer module (30) uses various techniques to normalize the data to say: 0.5999, 0.6011, 0.0742, 0.7493, and 0.3999 or if a data element has valid values such as 0, 1, 2, A, B, C – it can have normalized values of say 0.3242, 0.6343, 0.7565,0,3434,0.4564 & 0.2392

The position mapper module (40) is operably connected to the image encoder module (60). The image definition module (110) stores the final image size for each transaction. For example, if image size is of length “L” pixels and width “W” pixels, so the output image size would be “L x W” pixels. The position mapper module (40) stores a mapping between data element number and the corresponding x and y coordinate in the image where the data element’s normalized value gets stored.
For example, first 2 digits of the data element “processing code” represent the transaction code. The position mapper module (40) stores the configuration like:
Transaction code = (2, 5) which indicates that transaction code data element’s normalized value will be stored on x=2 and y=5 position in the image.

The channel mapper module (50) is operably connected to the image encoder module (60). The channel mapper module (50) stores the definition of data type to channel mapping. The channel mapper module (50) stores and understands the definition of each data element and attributes thereof. Based on the attributes, the channel mapper module (50) assigns an appropriate channel to the data element.

In case of images, channels represent the Red, Green and Blue (RGB) layers, also known as raster bands, which when overlaid on each other create the colour effect. In case of the transaction data, a similar concept is utilized and sometimes may also get referred to as feature map. For example, assuming a 4 channel setup for creating an image using CMYK as colour channels, the channel mapping would look like:
• C-channel – Stores categorical data as shown in figure 5a
• M-channel – Stores continuous data as shown in figure 5b
• Y-channel – Stores date and time data as shown in figure 5c
• K-channel – Stores other miscellaneous data in the transaction as shown in figure 5d

However, it is understood here that the different channel setups for creating the images using different colour channels may be utilized as per the type of the transaction data to be processed in other alternative embodiments of the present invention.

The image encoder module (60) takes inputs from the parser module (20), the normalizer module (30), the position mapper module (40), the channel mapper module (50) and the image definition module (110) to create an image. The image encoder module (60) picks up each data element received from the parser module (60) for a transaction along with value thereof and passes the data element along with value thereof to the normalizer module (30). The normalizer module (30) understands the data element and the received value and returns a normalized value back to the image encoder module (60). The image encoder module (60) then refers to a standard defined value for image size stored in the image definition module (110). The image encoder module (60) thereafter sends the data element as input to the position mapper module (40) and the position mapper module (40) returns the x, y coordinates corresponding to the data element. The image encoder module (60) passes the data element and value thereof to the channel mapper module (50). The channel mapper module (50) understands the data type and returns appropriate channel number to the image encoder module (60).

Using the inputs received from these modules (20, 30, 40, 50 and 110), the image encoder module (60) updates the value in “n” dimensional matrix of size “L x W x n4”, where:
• L = length of the image, indicating indices of x
• W = width of the image, indicating indices of y
• n4 = the number of channels/features (4 in case of the example above).
For example, to map merchant category code,
Merchant Category Code value = 5999
Normalized Merchant Category Code value = 0.5999
Merchant Category code data type = Categorical i.e. C-channel in this example
Merchant Category code pixel position= (4, 20)
Therefore, the image encoder module (60) populates a value of 0.5999 in C-channel at a position of x = 4 and y = 20.

The image encoder module (60) is operably connected to the transaction receiver module (10) and encodes the data received therefrom by applying the logic as explained above and coded in the program. The output of encoding is an image of a certain size as specified in the image definition module (110). The image definition module (110) stores the size (length x width, in pixels) of the image which represents the encoded transaction. In the context of the present invention, the data elements includes, but are not limiting to, message type, primary account number to identify a customer account or relationship, transaction type, source account, destination account, local time and date of the transaction, expiry date of the card, date of settlement, date of currency conversion, merchant category code, acquirer's country, fraud score for the transaction, EMI amount in case of EMI transaction, loyalty points balance, transaction currency code, cardholder billing currency code and the like.

The mapping dictionary module (70) is operably connected to the image encoder module (60). The mapping dictionary module (70) stores the mapping dictionaries of various transaction data elements with details such as field number, field value, field normalized value and pixel position in x and y coordinates. The mapping dictionary module (70) includes a data pre-processor module (not shown), a data-cleaner module (not shown) and a position lookup module (not shown) embedded therein. The data pre-processor module and the data-cleaner module identify the data points present in the transaction specification and map them to the field numbers. The data pre-processor module also identifies the number of data points, their sequence and matches those with the saved formats to automatically identify the specification.

The update module (80) is operably connected to the image encoder module (60) and is responsible for updating mapping tables with any fields or new data values in an existing field received in the transaction like a new data type, new data value and assigns appropriate position, channel and normalized value for future processing.

The store transaction module (90) is operably connected to the image encoder module (60). The store transaction module (90) stores the output of the encoded transaction into the transaction images database (100) thereby allowing the retrieval of the encoded transaction in future for learning, training and analytics.
In accordance with the present invention, for receiving real-time transactions, the system (150) exchanges server credentials and details and follow information security standards of either party to establish a server to server connection. The end user accesses the transaction data by logging onto an online portal hosted on a cloud. Alternatively, the portal can also be hosted on the client’s internal server (On-premise deployment). The client shares the list of users who need to access the system (150) and a system administrator then sets up the first time access credentials for the users. The users are allowed to setup their own password/dynamic passwords (like OTP) on first login and use the same to access the system (150) going forward. However, it is understood here that access to the system (150) can be restricted based on the role/function.

Referring to figure 6, in another aspect, a method for encoding the financial transactions in accordance with the present invention is shown. Specifically, the method involves converting the transaction data into an image format. In accordance with the present invention, the financial transaction data in real world are encoded into images by normalizing the data and by reducing the heterogeneity of the data, using the method of the present invention, instead of conventional way of storing and processing data in digits/numerals. The transaction details include the technology used, the person who made the transaction, place and type of transaction and like. This helps to define the image components and attributes or sub factors of each component. This information is further used to form an image format. The method is now described herein below in conjunction with the system figures 2-3.

Specifically, figure 6 shows the detailed flowchart of the method from step (201) to step (217). The method starts with offline activities like understanding transaction specification and creating position mapping dictionaries. At step (201), the method involves defining the transaction specification by studying the transaction specification to understand the data elements. In the context of the present invention, the data elements includes, but are not limiting to, message type, primary account number to identify a customer account or relationship, transaction type, source account, destination account, local time and date of the transaction, expiry date of the card, date of settlement, date of currency conversion, merchant category code, acquirer's country, fraud score for the transaction, EMI amount in case of EMI transaction, loyalty points balance, transaction currency code, cardholder billing currency code and the like.

At step (202), the method involves classifying data element types. The data elements are classified into data types such as categorical, continuous, date and time, geo-location and the like. Each data type is assigned a channel by the channel mapper module (50) as shown in figures 5a-5d.

At step (203), the method involves defining an image size in the image definition module (110), position of data elements and channels thereof by the position mapper module (40). The image size is defined/ determined based on the transaction specification to ensure all data elements in the specification are represented in the image within the image size and number of channels.

At step (204), the method involves creating a mapping dictionary of the data elements. The mapping dictionary is created which is accessed by required modules in the image encoder to perform their operations. The dictionary includes, but not limited to, data element number, data element, data type, data element value, data element normalized value and data element pixel position. Specifically, the mapping dictionaries are pre-created as per the domain specification and data elements involved. These are created as part of the initial data analysis and for each data element in the specification a corresponding mapping dictionary is selected.

At step (205), the method involves receiving a transaction by the transaction receiver module (10). The transaction is received in any one of real-time and batch mode/bulk. The real-time transactions are received in TCP/IP or other real-time messaging protocols and the batch/bulk transactions are received via the file transfer protocol such as secure copy protocol (SCP) to a specified folder on a server. However, it is understood here that the transaction receiver module (10) may receive transaction using any other protocol in other alternative embodiments of the present invention. The transaction data has to be shared in a delimited file and for that a unique transaction reference number is assigned to each new incoming transaction.

At step (206), the method involves breaking the transaction string/message into individual data elements by the parser module (20). The data elements are then put in a message queue for the other modules to consume individual data elements. The parser module (20) performs the parsing operation according to the transaction specification.

At step (207), the method involves determining whether the transaction specification is available by referring the mapping dictionary module (70). Data specification of the incoming data is identified by matching the format of the data with a ‘use case’ specification stored in the system (150). The data pre-processor module embedded in the mapping dictionary module (70) identifies the number of data points, their sequence and matches those with the saved formats to automatically identify the specification. If the transaction specification is not available then a new specification is created at step (208). Thereafter, whether all data points of the new specification are auto-identified is checked at step (209). If all the data points of the new specification are identified then that specification is saved as new specification at step (210) else method moves to step (211).

On availability of the transaction specification, the method involves determining whether all the data points are defined in the mapping dictionary module (70) at step (212). The data pre-processor module and the data-cleaner module of the mapping dictionary module (70) identify the data points present in the transaction specification and map them to the field numbers. If all data points are not defined in the mapping dictionary module (70), then the method involves identifying whether there is any new type of data point at step (211). The mapping dictionary module (70) includes a list of valid values for each of the base data field. The mapping dictionary module (70) automatically identifies the values present in the data points and confirms if all values are already mapped to define new data-type at step (213). If the values are not mapped then new position and channel values are introduced to the mapping dictionary module (70) at step (214).

On availability of all data points in the mapping dictionary module (70), the method involves mapping data points to pixels in the position lookup module by converting transaction data points as per the mapping dictionary module (70) at step (215). The mapping dictionary module (70) includes a mapping of data point value to a pixel value. The transaction data points are replaced by equivalent pixel values. The pixel values of the images are used to store the data point attributes. As the pixels carry a variety of combination of bits, the image format provides much more data capacity than a standard transaction format built using structured sequences. Also, this provides a very efficient technique by packing more information in the same memory. In an embodiment, pixel colors are used to store additional attributes

At step (216), the method involves creating an image by the image encoder module (60). After all the pixel values for all data points in the transaction are assigned using the mapping dictionaries, the image encoder module (60) forms an image of a pre-defined size for e.g. 24 x 24 or 48 x 48 and plot the pixel at the pre-defined location in the image. When all pixels are added to the image the final image of the transaction is formed. Transaction data is converted into an array, similar to how images are stored. One array represents one transaction, which in other words is an image of a fixed size, with fixed pixel position for each data element and a fixed colour as per the mapping dictionary.

In final step (217), the method involves storing the image by store transaction module (90) in the transaction images database (100). The image is stored against the same transaction reference number which is assigned when a new transaction is received by the system (150). Specifically, the image is stored in the transaction images database (100) as a volume represented by pixel position x, y and colour channel intensity values for example, R, G, B or C, M, Y, K.

The transaction data stored in the form of images is used for training machine to learn the patterns from these images. The normalization and encoding step helps reduce dimensionality of the transaction data and bring uniformity in scale and type of data. The data is in the form of images and hence facilitates application of an image processing machine learning algorithms. The machine learning algorithms use the stored and encoded transaction data to learn about the patterns in the transaction and train the models. Specifically, the stored images in the transaction images database (100), in the form of data frames/arrays, are retrieved for training. The array has values for example between [0, 255] for the RGB colours. In order to run machine learning thereon, the array is rescaled to a value between 0 and 1. Thereafter, a standard image processing algorithm like a Convolutional Neural Network is applied to these large numbers of images. The results like accuracy and loss are reviewed to determine if the data is sufficient or less, is it over-fitting or right, presence of noise and the like. The standard data augmentation techniques like flip, rotate and zoom are used to create additional data for the machine to improve the learning by ignoring noise or avoiding over-fitting. Thereafter, the model is compiled and an output model file is created to process any new image being fed thereto. The created model also classifies the new images accurately in either of the classifications on which it has been trained before. The models are used by the business teams to assign score to the transaction. The score is used for prediction and forecasting and also useful for multiple applications like taking a risk based approval decision or declining a transaction.

In another embodiment, the processed data of the system (150) and the method are transferred to a machine learning algorithm. In this one embodiment, the machine learning algorithm is compatible to process the alphanumeric characters hence the data of the system (150) is first sent to a decoder (not shown). The decoder decodes the transaction encoded in the image or brought back to an original form of alphanumeric characters. Some data points from the original transaction have to be stored as received for the decoding process. For example, the data points which are encoded using a bucketing technique. The original values of these data points are stored against the transaction reference number so that it can be restored/retrieved during the decoding process.

The continuous data points like amount are encoded by bucketing them in say 0-100, 100-500 and the like. The actual transaction amount is stored against the transaction reference number. When decoding starts, the system (150) retrieves the continuous fields from the database saved against the transaction reference number and replaces them at the appropriate data point. The discrete data points like flags and categories are decoded by referring the decoding dictionaries. These dictionaries are exactly same as the encoding dictionaries, except the fact that keys and values are swapped. For example, if key is ‘POS’ and value is ‘(3, 17)’ on Y-channel in the encoding dictionary, the decoding dictionary has ‘Y (3, 17)’ as the key and ‘POS’ as the value. The decoding process reads the images and restores the categorical fields.

In an exemplary embodiment, to encode the transactions in the form of images, a merchant category code is allotted a pixel position (2, 18), transaction amount is allotted a pixel position (3, 15) and transaction code is allotted a pixel position of (4, 20). Whereas, colour channels (RGB or CMYK or any other combination) are used to represent one type of data. In this one example, the CMYK channel is used. Cyan or C-channel stores all categorical/discrete data elements, e.g transaction code is a categorical data point hence it is mapped to C channel and its respective x, y position i.e. (4, 20). In another example, a merchant category code is also a categorical data and had assigned a x, y position of (2, 18) to it. The pixel (2, 18) on C channel is used to store the normalized value of merchant category code present in the transaction. In this one example, magenta or M- channel stores all continuous data elements such as transaction amount, fee amount and like. So transaction amount’s normalized value is stored in an x, y position of (3, 15) on M channel. Whereas, a yellow or Y-channel stores miscellaneous data types apart from categorical and continuous data types such as date and time, geo-location co-ordinates (latitude, longitude), MAC address of a device, IP address of a request origination on internet and the like. As an example, normalized value of device IP address of a laptop from where transaction originates is stored at an x, y position of (10, 24) on Y-channel. A black of K channel is used to store derived data or enriched data populated by the system (150) on the basis of historical data related to an entity. As an example, average transaction amount for a cardholder or daily transaction count for a cardholder or % of credit limit exhausted by card. Thus, the image can be formed by using this encoding standard which maps the transaction data elements to pixel positions and channels they belong to.

Advantages of the invention:

1. The system (150) and the method eliminate the difficulties in processing a large amount of heterogeneous alphanumeric data by encoding the heterogeneous alphanumeric the data into an image format as the images can be processed in a better way by using advancements in image processing machine learning algorithms and image processing hardware thereby increasing the operational efficiency.
2. The data engineering efforts required for normalization of heterogeneous alphanumeric data is avoided with the image based processing. The images also provide a different way of normalizing various data points and these will also be faster in terms of training the machine.
3. The system (150) and the method provide a transaction score in real-time thereby helping the financial institutions to take an informed decision.
4. The system (150) and the method combine normalization and dimensionality reduction of the transaction data in a single step using the mapping dictionary.
5. The encoding of the images using the system (150) and the method open up possibilities of applying computer vision algorithms to the transaction data. The parameters required for a computer vision algorithm such as convolutional neural network are far less than a conventional neural network. This would save huge amount of system processing time and power required to train a machine learning algorithm on a historical transaction data.
6. The encoding of the images using the system (150) and the method can potentially save the storage space. For example, date (DDMMYYYY) in a conventional alphanumeric representation requires minimum 4 bytes of memory if binary coded decimal encoding is used to store the data, otherwise it requires 8 bytes to store each individual numeral. Further, with the image encoding using the present invention, a day is represented as a category containing 1 to 31 categories, which are represented in 1 pixel using 31 intensities of the appropriate channel. Similarly a month is represented as 12 categories, from 1 to 12, stored as 12 intensity values of a pixel and similarly for year, mapping a 255 calendar years using 255 intensity values of a pixel is possible.
7. The system and the method further facilitate designing of a special purpose hardware to process transactions encoded using the present invention to speed up the training process.

The foregoing descriptions of specific embodiments of the present invention have been presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the present invention to the precise forms disclosed, and obviously many modifications and variations are possible in light of the above teaching. The embodiments were chosen and described in order to best explain the principles of the present invention and its practical application, and to thereby enable others skilled in the art to best utilize the present invention and various embodiments with various modifications as are suited to the particular use contemplated. It is understood that various omissions and substitutions of equivalents are contemplated as circumstances may suggest or render expedient, but such omissions and substitutions are intended to cover the application or implementation without departing from the scope of the present invention.
,CLAIMS:We claim:

1. A system (150) for encoding the financial transactions, the financial transactions being facilitated by the system (150) using a point of origination device connected to a router (160), an acquiring switch server (170), a payment network (180) and an issuing switch server (190), the system (150) comprising:
a transaction receiver module (10) embedded in the issuing switch server (190) for receiving a transaction and performing decoding of a transaction message received from a source;
a parser module (20) embedded in the issuing switch server (190) and operably connected to the transaction receiver module (10) for receiving transaction therefrom, the parser module (20) capable of breaking the transaction message into individual data elements using specification definitions;
a normalizer module (30) having a predefined normalized value for each data element stored therein;
a position mapper module (40) for storing mapping between data element number and the corresponding x and y coordinate in an image;
a channel mapper module (50) for storing definition of data type to channel mapping and definition of each data element and attributes thereof;
an image definition module (110) for storing the size of the image;
an image encoder module (60) capable of taking inputs from the parser module (20), the normalizer module (30), the position mapper module (40), the channel mapper module (50) and the image definition module (110) to create the image;
a mapping dictionary module (70) operably connected to the image encoder module (60) for storing the mapping dictionaries of various transaction data elements, the mapping dictionary module (70) having a data pre-processor module, a data-cleaner module and a position lookup module embedded therein;
an update module (80) operably connected to the image encoder module (60) for updating mapping tables with any new fields or new data values in an existing field received in the transaction; and
a store transaction module (90) operably connected to the image encoder module (60) for storing an output of the encoded transaction into a transaction images database (100),
wherein, after all the pixel values for all data points in the transaction are assigned using the mapping dictionaries, the image encoder module (60) forms an image of a pre-defined size and plot the pixel at the pre-defined location in the image to form a final image of the transaction.

2. The system (150) as claimed in claim 1, wherein the transaction receiver module (10) receives the transactions in any one of real-time and batch/bulk mode.

3. The system (150) as claimed in claim 1, wherein the normalizer module (30) stores the mapping of data element and along with valid values of the data element, normalization technique to be used to normalize the data and the final normalized value against each value in the data element.

4. The system (150) as claimed in claim 1, wherein the mapping dictionary module (70) stores the mapping dictionaries of various transaction data elements with details such as field number, field value, field normalized value and pixel position in x and y coordinates.

5. The system (150) as claimed in claim 1, wherein the data pre-processor module and the data-cleaner module identify the data points present in the transaction specification and map them to the field numbers.

6. A method for encoding the financial transactions, the method comprising the steps of:
defining a transaction specification by studying the transaction specification to understand data elements;
classifying data element types, wherein each data type is assigned a channel by a channel mapper module (50);
defining position of the data elements and channels thereof by a position mapper module (40);
creating a mapping dictionary of the data elements;
receiving a transaction by a transaction receiver module (10), wherein the transaction receiver module (10) is embedded in an issuing switch server (190), transaction receiver module (10) performs decoding of a transaction message received from a source;
breaking the transaction message into individual data elements by a parser module (20);
determining the transaction specification by referring a mapping dictionary module (70);
determining whether all the data points being defined in a mapping dictionary module (70) by a data pre-processor module and a data-cleaner module on availability of the transaction specification;
mapping data points to pixels in a position lookup module by converting transaction data points as per the mapping dictionary module (70) on availability of all data points in the mapping dictionary module (70);
creating an image by an image encoder module (60), wherein after all the pixel values for all data points in the transaction are assigned using the mapping dictionaries, the image encoder module (60) forms an image of a pre-defined size and plot the pixel at the pre-defined location in the image to form a final image of the transaction; and
storing the image by a store transaction module (90) in a transaction images database (100).

7. The method as claimed in claim 6, wherein the transaction receiver module (10) receives the transactions in any one of real-time and batch/bulk mode.

8. The method as claimed in claim 6, wherein a mapping dictionary module (70) stores the mapping dictionaries of various transaction data elements with details such as field number, field value, field normalized value and pixel position in x and y coordinates.