FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003
COMPLETE SPECIFICATION
(See section 10, rule 13)
1. Title of the invention: UNIFIED CLEARING SYSTEM
2. Applicant(s)
NAME NATIONALITY I ADDRESS
TATA CONSULTANCY Indian Nirmal Building, 9th Floor, Nariman Point,
SERVICES LIMITED Mumbai 400021, Maharshtra,
India
3. Preamble to the description
COMPLETE SPECIFICATION
The following specification particularly describes the invention and the manner in which it
is to be performed.

TECHNICAL FIELD
The subject matter described herein, in general, relates to systems and methods for trading in financial markets and, in particular, relates to a unified system for clearing of trades in financial markets.
BACKGROUND
In banking, and finance, a trade or a financial transaction denotes the transfer of ownership of goods and services from one person to another. A transaction, in particular, involves an event arising out of an agreement between two parties, a buyer and a seller, to exchange certain assets, economic resources, or services for an amount of payment. The trade, interchangeably also referred to as a transaction, is considered settled following transfer of ownership of the assets and disposal of obligations arising out of the agreement. A number of risks arise for the parties until the transaction is settled. These risks need to be managed by a process called clearing, which follows the execution of the trade and precedes settlement. Clearing includes processes such as trade management, position management, risk management, and settlement functions. The key functions include reporting/monitoring trades, risk margining, netting of trades to positions, tax handling, and failure handling.
Generally, a clearing house provides clearing and settlement services for financial transactions, as well as transactions related to commodities, derivatives, and securities. The transactions may be executed on, for example, a futures or derivatives exchange, a spot or cash exchange, a securities exchange, or off-exchange as in the case of over-the-counter (OTC) markets. As there is a difference in the nature of settlement of the trades, or transactions, with regard to different types of trades that currently exist, or may exist in future, clearing related processes may also differ. For example, clearing in cash

markets is inherently different from clearing in derivative markets as, in the former, the trades are settled instantaneously or 'n' days after the trade execution (where n can be 1, 2 or 3 or in some cases up to 7), while in the latter, the trades are subject to settlement at a much later date, say after one month, six months, or more.
Clearing houses need to implement different clearing systems and/or infrastructures supporting such systems, in order to meet requirements of different types of exchanges that have investors investing in different types of trade. In addition, as more and more exchanges have started diversifying into derivatives market, clearing houses too need to keep themselves updated with the latest in technology. Some conventional systems are being used to clear spot trade/cash market trade while some are for the derivatives market. However, procuring asset class-specific or market specific clearing systems proves cost ineffective not only for the clearing houses but also for the investors dealing through such clearing houses.
SUMMARY
This summary is provided to introduce concepts related to trading in financial markets. These concepts are further described below in the detailed description. This summary is neither intended to identify essential features of the claimed subject matter nor is it intended for use in determining or limiting the scope of the claimed subject matter. The subject matter described herein relates to systems and methods for clearing trades from a unified clearing system irrespective of an underlying trade type. In an embodiment, the method implemented by the system includes receiving an information set from an entity for carrying out a trade in a tradable instrument, the information set includes at least one attribute of an offer made by the entity, identifying at least one trade type amongst a plurality of trade types based on the information set, and clearing the trade

based on the trade type by at least computing a value of at least one obligation arising out of the trade.
BRIEF DESCRIPTION OP THE DRAWINGS
The detailed description is provided with reference to the accompanying
figures. In the figures, the left-most digit(s) of a reference number identifies the figure in
which the reference number first appears. The same numbers are used throughout the
drawings to reference like features and components.
Fig. 1 illustrates an exemplary environment for implementing a unified clearing
system, in accordance with an implementation of the present subject matter.
Fig. 2 illustrates various components of a unified clearing system, in
accordance with an embodiment of the present subject matter.
Fig. 3 illustrates a method for clearing trades, in accordance with an
implementation of the present subject matter.
DETAILED DESCRIPTION
The subject matter described herein relates to systems and methods for processing transactions in financial markets. The subject matter, in particular, relates to clearing of trades involving one or more tradable instruments such as commodities, securities including stocks, bonds, etc., or derivatives including futures and options on commodities, stocks, bonds, index, etc. A trade may be capable of being executed in one or more markets, market segments, or exchanges irrespective of a trade type associated with the trade.
As would be appreciated by a person skilled in the art, in almost every financial market value chain, clearing is a key component of settlement of trades. Once an order for trading a tradable instrument is executed between a buyer and a seller, the parties incur

certain obligations to each other so as to settle the irade at a specified date and time. In order to fulfill the obligations, the parties may make certain exchanges, which may involve payments made, transfer of the tradable instruments), services, etc., all of which need to be cleared in preparation for the transfer of ownership of the tradable instrument, and fulfillment of the related obligations. In order to streamline the whole process and to ensure fewer cash flows and evaluation and management of all relevant sources of risks, different services may be performed as part of the clearing process.
Clearing may be performed at different levels, for example, by a trading party for its client (another party), at a central counterparty clearing house (CCP Clearing), and at a central security depository (CSD/ICSD Clearing) or a banking institution (for internal executions), and may involve services such as trade management, netting, position management, risk management, and collateral management. In netting, values corresponding to one or more exchanges between the parties are offset with same tradable instrument or underlying and attribute, such as contracting party, security type, trading currency, etc., into one net obligation. The net obligation for one party trading in securities, for example, may be in cash or part cash and part securities. Alongside netting, any counterparty exposure to outstanding obligations is evaluated and calculated, through a process known as risk management. Subsequently, counterparty assets are controlled against the exposure as calculated.
Conventionally, clearing in different markets or market segments involves separate clearing systems and/or infrastructures supporting such systems. This is because each market or market segment has its own set of rules for the settlement of a trade. Thus, a clearing house providing clearing services to a varied group of investors needs to have a variety of systems to meet the growing market demands. Procurement and maintenance of different systems and/or infrastructures is not always a cost-effective solution for small to

mid-size clearing houses. Even investors dealing through the clearing houses incur overhead costs resulting from capabilities up-gradation of such clearing houses. The present subject matter provides for a unified clearing system and a method for clearing trades irrespective of a trade type or the exchange in which the trade is being executed. The unified clearing system described herein is capable of catering to the needs of different investors trading in different markets and market segments through a single, unified system without the need for a plurality of varied systems and infrastructures. In an embodiment, the unified clearing system, or hereinafter interchangeably as the clearing system, may receive an information set from an entity, for example, an external trade source, for carrying out a trade of a tradable instrument. The clearing system may receive the information set via a data layer, which acts as a common reference data layer for all kinds of trades being executed in an exchange. The information set may include one or more attributes of an offer for a trade made by the entity, for example, attributes corresponding to an offer to sell or an offer to buy. In an implementation, the information set may also include information of at least one second entity involved in the trade.
Based on the information set. at least one trade type, from a plurality of trade types, is identified. Each trade type may be based on a combination of attributes that define the way the underlying trade may be settled. The clearing system may store a plurality of combinations of all such attributes in the form of predefined parameter(s). In an implementation, at least one attribute amongst the attributes of the offer is compared with a predefined parameter to identify the trade type. In another implementation, a group of attributes may also be compared with a group of predefined parameters. The attributes may include, for example, a trade date, a settlement date, an expiry date, a trading currency, a trading exchange, a clearing organization, a place of settlement (such as a

CSD), and a type of the tradable instrument. The trade type may include, for example, a cash trade and derivatives trade including futures and options trades. In an implementation, the trade is cleared to arrive at a cash obligation for a tradable instrument. The trade may also be cleared to arrive at a cash obligation across a number of tradable instruments for a trading currency. Similarly, for options trade, for example, a trade may be cleared to arrive at a net premium amount (cash obligation) for a tradable instrument, or an underlying tradable instrument across a number of tradable instruments, or a currency across the underlying tradable instruments and the tradable instruments, or a combination thereof. The clearing system achieves the same by setting appropriate netting levels. In an implementation, attributes may be deleted from and added to the netting level ID. In one implementation, the value of obligations may include a position value of the tradable instrument. The position value may further include one of a futures position, an options position, a swap position, and a premium settlement value. As will be appreciated by a person skilled in the art, the clearing system acts as a unified clearing system and supports multiple exchanges, markets, market segments, clearing houses, place of settlements (such as CSDs), asset classes, and currencies. The clearing system may be applied to and modified for both the cash and derivatives markets. The clearing system is configured in such a manner that it avoids duplication of data and saves time and effort in carrying out functions associated with clearing. In addition, the clearing system may be integrated into existing frameworks of clearing houses without requiring any further implementations or compatibility modules.
While aspects of the described system(s) and method(s) for clearing trades in tradable instruments can be implemented in any number of different computing systems, environments, and/or configurations, the embodiments are described in the context of the following exemplary system architecture(s).

Fig. 1 illustrates an exemplary network environment 100 for implementing a
unified clearing system 102, in accordance with an embodiment of the present subject matter. The network environment 100 may include entity 104-1, 104-2... 104-N. collectively referred to as entities 104. The entities 104 may include buyers, sellers, wholesale traders, representatives of the buyers/sellers/wholesale trade, market makers, exchanges, external trade sources, banks, financial institutions, brokerage firms, electronic money accounts, communication account providers, electronic information providers, and electronic transaction intermediaries. In one implementation, the entities 104 may be communicatively coupled to the unified clearing system 102 through the network 106. The network environment 100 can be an office network including a plurality of personal computers, laptops, various servers, such as blade servers, and other computing devices connected over the network 106. Additionally, the entities 104 may communicate with the unified clearing system 102 using communication devices or "user devices" (not shown) such as computers, laptops, cellular phones, and palmtops, and accordingly may be interchangeably referred to as user devices 104.
The network 106 may be a wireless network, a wired network, or a combination thereof. The network 106 can also be an individual network or a collection of many such individual networks, interconnected with each other and functioning as a single large network, e.g., the Internet or an intranet. The network 106 can be implemented as one of the different types of networks, such as intranet, local area network (LAN), wide area network (WAN), the internet, and such. The network 106 may either be a dedicated network or a shared network, which represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), Wireless Application Protocol (WAP), etc., to communicate with each other. Further, the network 106 may

include network devices, such as network switches, hubs, routers, HBAs, for providing a link between the unified clearing system 102 and the entities 104.
In one implementation, the unified clearing system 102 is configured to receive a trade request for trading in a tradable instrument, assign a trade type to the trade request, compute a value, which is a net value, of obligations arising out of the trade, and clear the trade. The tradable instruments may include commodities, stocks, bonds, fixed income securities, etc.
In an implementation, an entity 104, for example, an exchange, a multilateral trading facility (MTF), or any other regulated market, initiates a request, using one of the communication devices, for executing or carrying out a trade in a market. The request is communicated to the unified clearing system 102 via the network 106. In an implementation, the unified clearing system 102 receives the request through a common reference data layer (not shown). In such a case, the common reference data layer can be configured to avoid duplication of data and results in time saving and the effort in carrying out clearing functions.
Further, the unified clearing system 102, hereinafter interchangeably referred to as the clearing system 102, receives trades from an exchange or a trade source. The trade includes an information set. The information set may include data related to a buyer, a seller, an exchange on which trading happened, etc. For example, an information set may include an entity, say the entity 104-1, initiating the request or the trade source; or say the entity 104-1 initiating the request, the traded instrument, details of the traded instrument such as lot size, strike, option type, traded currency, traded quantity, traded price; trade/settlement/expiry date; client references for whom the trade has been executed; textual remarks, etc. In an implementation, the information set may also include information of another entity, say entity 104-2, involved in the trade.

After receiving the request, the clearing system 102 identifies a trade type based on the request, i.e., based on the information set received as part of the request. In one implementation, the trade type is identified by comparing an attribute in the information set with at least one predefined parameter. The predefined parameter may be one of a wide range of business parameters that generally govern the way a trade is executed. In an implementation, the predefined parameter may include an exchange, a clearing house, a CSD, a tradable instrument, a currency or a date like trade date, settlement date, expiry date, or any other parameter relevant to the trade. Based on the comparison, the trade type is identified and the trade is cleared marking the settlement of the transaction. In an implementation, in order to clear the trade, the clearing system 102 computes the value, or interchangeably the net value, of obligations arising out of the trade.
For example, in case of cash trade, the clearing system 102 establishes a net obligation value to be settled for each instrument traded in one or more markets, market segments, or exchanges. The clearing system 102 may suggest, for example, the cash to be settled, the number of instruments bought or sold, price paid for each instrument bought or sold, the cumulative bought or sold, etc. In case of options trade, the clearing system 102, may suggest a position value of the instrument traded. In an implementation, the clearing system 102 may also suggest, in case the trade type is an options trade, a premium to be paid instantly or after a term in addition to a suggesting a position value for the underlying options contract. The clearing system 102 may also determine, for information purpose, total number of premiums one has to pay for the options contract. Once the net value of obligations is computed, the clearing system 102 may add the net value to a netting \evd ID corresponding to the trade type and then clears the trade. Concept related to netting

level ID has been discussed in detail in the subsequent figure description. The working of the clearing system 102 is further explained in detail in conjunction with Figs. 2-4. Fig. 2 illustrates components of the clearing system 102, in accordance with an embodiment of the present subject matter. The clearing system 102 includes processor(s) 202, interface(s) 204 and a memory 206. The processor(s) 202 can be a single processing unit or a number of units, all of which could include multiple processing units. The processor(s) 202 may be implemented as one or more microprocessor, microcomputers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities the processor(s) 202 are configured to fetch and execute computer-readable instructions stored in the memory.
The interface(s) 204 may include a variety of software and hardware interface, for example, interface for the user device(s) 104. The peripheral devices connected through the interface(s) 204 facilitate receiving of trade offers from one or more exchanges or markets or clearing houses. The devices would also facilitate the access to the clearing system 102 for purposes such as viewing and modifying details in the trade offers.
The memory 206 may include any computer-readable medium known in the art including, for example volatile memory such as SRAMs and DRAMs and/or non-volatile memory such as EPROMs and flash memories. The memory 206 further includes module(s) 208 and data 210. The module(s) 208 include trade type identification module 212, netting pool identification module 214, netting pool updation module 216. and other module(s) 218. The other module(s) 218 include programs that supplement applications or functions performed by the clearing system 102, such as process optimization.

Further, the data 210 serve, amongst other things, as repositories for storing data such as parameter data 220, attribute data 222 and other data 224. The data 220 may include, for example, one or more attributes, different combinations of attributes relating to different trade types. The other data 224 may include any of the instructions, inference rules which are required for the functioning of the clearing system 102. The operation of module(s) 208 synchronized with data 210 is discussed in detail in the following description.
Further, the data 210 may include parameter data 220 in the form of metadata and other data 224. In one implementation, the parameter data 220 may include a plurality of business or transaction related parameters, such as currency, exchange, lot size, price, market or market segment, which may govern the way a trade executes in the clearing system 102, for example, on acceptance, cancellation, modification, position composition, etc.
During operation, the trade type identification module 212 identifies a trade type pertinent to the trade being executed. As also indicated previously, the trade being executed can be initiated based on an offer from an entity, for example, the entity 104-1. Once such an offer is received by the clearing system 102, the trade type identification module 212 determines the attributes that are associated with the offer. Once the attributes are identified, the trade type identification module 212 compares the attributes with one or more predefined parameters stored in the parameter data 220, As also mentioned earlier, the predefined parameter(s) may be business parameters that govern the way a trade is executed and may include exchanges, clearing houses, CSDs, tradable instrument(s), currency, trade related dates, etc. Based on the comparison, the trade type identification module 212 identifies the trade type. The attributes of the trade may include any one of a settlement date, a trade date, an expiry date, a trading currency, a trading exchange, a

clearing organization, a type of the tradable instrument, etc.. which can be stored as attribute data 222. The trade type identified may be one of a cash trade, futures trade, and options trade.
In another implementation, the netting pool identification module 212 identifies whether a netting pool, that is, a group of the attributes corresponding to the trade type, exists. As already mentioned earlier, such attributes are received as part of the instruction set. A netting pool may be understood as a set of attributes that determines at what level the net value of obligations has to be computed in order to clear the trade. Netting level can be defined as a level corresponding to the number of attributes in a netting pool. The netting level may also be defined in terms of addition and removal of attributes to and from a netting pool so as to form a netting pool of a different level. In an implementation, the netting pool identification module 212 searches a netting pool ID corresponding to the trade type within the existing netting pool IDs stored in the clearing system 102. In case a netting pool ID corresponding to the trade type as identified does not exist, the netting pool identification module 212 creates a new netting pool ID. Once the netting pool ID is found to exist or is created afresh, the netting pool updation module 214 aggregates a net value of obligations for the entity requesting the trade and adds that net value to the netting pool ID.
Consider a netting pool having the following attributes for calculating fund obligations of a buyer: exchange, market, and segment. This implies that for each buyer. fund obligations will be computed at the following netting levels: exchange, market, and segment levels. Consider a buyer A in some market, say Ml, who intends to trade in that market and various other markets (M2 and M3) and segments (S2 and S3) of those markets. In addition, A may also intend to trade cash in securities (SEC01 to SEC04) through different exchanges (El to E3) with one or more sellers (B to J), which may be

operating in the same market as A or in different markets. In such a case, A may be considered to be an external trade source to these sellers B to J. In order to settle different trades, A has to make a number of payments for each lot of securities purchased in each segment. The aforesaid has been illustrated in the Table 1.

s.no.. Buyer Seller Exchange Market Segment Security Quantity Price
i A B El Ml S1 SEC01 10 100
2 A C El Ml S1 SEC02 20 100
3 A D El Ml S2 SEC03 15 100
4 A E E2 Ml S1 SEC01 10 100
5 A F E2 M2 S1 SEC02 15 100
6 A G E3 M3 S2 SEC03 20 100
7 A H E3 Ml S1 SEC04 10 100
8 A B E3 Ml S1 SEC01 15 100
Based on the values in Table 1, and taking into consideration the three netting levels for the present example, i.e., market, exchange, and segment, fund obligations of A in each market-exchange-segment combination can be calculated in the following way as shown in Table 2:

Exchange Market Segment Total
El Ml S1 (10* 100)+ (20* 100) =3000
El Ml S2 (15 * 100) = 1500
E2 Ml S1 (10* 100)= 1000
E2 M2 S1 (15* 100) =1500
E3 M3 S2 (20* 100) = 2000
E3 Ml S1 (10* 100)+ (15* 100) = 2500
The netting pool updation module 216 facilitates computing or updating of the net value of obligation(s) at different levels, for example, security obligation at tradable instrument level, cash obligation at tradable instrument level, cash obligation at currency

level, etc. In addition, the netting pool updation module 216 facilitates addition and removal of the attributes to and from the netting pool(s). The trade type identification module 212, the netting pool identification module 214, the netting pool updation module 216. and the other modules 218 may communicate with one another and/or with devices external to the clearing system 102 via methods known in the art. The other modules 218 may include modules such as risk assessment module (not shown) for estimating financial risks associated with the trade and a banking module (not shown) to request transfer of funds to settle the trade based on an updated value of the obligation(s). Such modules are not part of the present subject matter and hence are not discussed in detail. The trade can be finally settled by making the required payment, that is, the sum total of payments corresponding to net value(s) for each netting poo), through, for example, a banking institution or in person, over-the-counter.
Fig. 3 illustrates an exemplary method 300 for clearing trades, in accordance with an implementation of the present subject matter. It will be understood that although the method described herein is in context of the clearing system 102, other systems having similar functionalities may also be conceived.
The exemplary method may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, functions, etc., that perform particular functions or implement particular abstract data types. The method may also be practiced in a distributed computing environment where functions are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, computer executable instructions may be located in both local and remote computer storage media, including memory storage devices.

The order in which the method 300 is described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method, or an alternative method. Additionally, individual blocks may be deleted from the method without departing from the spirit and scope of the subject matter described herein. Furthermore, the method 300 can be implemented in any suitable hardware, software, firmware, or combination thereof.
With regard to Fig. 3, at block 302, a trade request is received. For example, the clearing system 102 may receive the request from one or more entities 104. In one implementation, an entity sending request, for example, the entity 104-1 can be an external trade source.
At block 304, an information set associated with the trade request is determined. For example, the trade type identification module 212 determines the information set that is associated with the trade request received from the entity 104-1. In one implementation, the information set includes one or more attributes associated with the offer for the trade. The attributes may define a level of netting or computing of a net value of obligations arising out of the trade.
For example, the information set may include data related to a buyer, a seller, an exchange on which trading happened, etc. The information set may include, say the information associated with a trade source such as the entity 104-1 initiating the request; information of the trade source, a traded instrument, details of the traded instrument such as lot size, strike, option type, traded currency, traded quantity, traded price; trade/settlement/expiry date; client references for whom the trade has been executed; or textual remarks. In an implementation, the information set may also include information of another entity, for example, the entity 104-2, involved in the trade.

Further, at least one attribute is compared with a predefined parameter. For example, an expiry date of the offer is compared with a corresponding predefined parameter for example, stored in a look-up table, as is known in the art. A plurality of predefined parameters may be stored in the clearing system 102 as parameter data 220. At block 306, at least one trade type of the trade request is identified. For example, the trade type identification module 212 compares the attributes included within the information set with one or more predefined parameters included within the parameter data 220. As indicated previously, the attributes may include a settlement date, a trade date, an expiry date, a trading currency, a trading exchange, a clearing organization, a type of the tradable instrument, etc. In one scenario, the attribute may be the date of the transaction. As would be known to a person skilled in the art, the transaction date for spot trading typically would be within, say two days, from the date of the trade offer. Therefore, if the trade type identification module 212 determines the attribute — date of transaction -- to be less than two days, the trade type identification module 212 can identify the present trade type to be a spot trade. In one implementation, the attributes can be stored in attribute data 222. Based on the comparison of the attribute data 222 and the parameter data 220, the trade type identification module 212 determines the trade type. For example, the type of the tradable instrument may become the basis for the trade type identification module 212 for determining the trade type. It will be appreciated that the present example has been provided as an exemplary implementation, and should not be construed to be a limitation. Other implementations would also be within the scope of the present subject matter.
At block 308, the trade is cleared based on the trade type. For example, in case the trade type is identified as cash trade, then a net value of obligations arising out of the trade is settled instantaneously or at maximum a day after. In case of derivatives or futures

trade, a position of the tradable instrument being traded is settled. In addition, in case of options, a net premium value is provided in addition to a net position of the tradable instrument to be paid at the time of settlement or after such a date before the contract expires.
Further, in order to clear the trade a netting level identity (ID) corresponding to the trade type is determined. In case a netting pool corresponding to the trade type does not exist, a new netting pool is created and is assigned a netting pool identity (ID). For example, the netting pool identification module 216 determines whether a netting pool exists for the one or more attributes received, when taken as a group. In case the netting pool identification module 216 determines that no netting pool exists, the netting pool identification module 216 may create a new netting pool ID. Subsequently, a net value of the obligations is added to the newly created netting pool ID. On the other hand, in case the netting pool identification module 216 determines the existence of a netting pool ID for the group, the net value of the obligations is added to the existing netting pool ID. Subsequent to computation of the net value, the net value is added to the netting pool ID and the trade is cleared.
The trade can be finally settled by making the required payment, that is, the sum total of payments corresponding to net value(s) for each netting pool, through, for example, a banking institution or in person, over-the-counter.
Although embodiments of the unified clearing system for the clearance of tradable instruments have been described in language specific to structural features and/or methods, it is to be understood that the invention is not necessarily limited to the specific features or methods described.

I/We claim:
1. A unified clearing system (102) comprising:
a processor (202);
a memory (206) coupled to the processor (202), wherein the memory (206) comprises,
a trade type identification module (212) to identify a trade type amongst a plurality of trade types based on one or more attributes associated with a trade;
a netting pool identification module (214) to identify a netting pool corresponding to the trade type, the netting pool being indicative of a set of the one or more attributes that determine a level of netting; and
a netting pool updation module (216) to update, based on the level of netting, a value of at least one obligation arising out of the trade.
2. The unified clearing system (102) as claimed in claim 1, wherein the attributes comprise at least one of a trade date, an expiry date, a settlement date, an exchange, a clearing house, a central security depository, a tradable instrument, and a currency.
3. The unified clearing system (102) as claimed in claim 1, wherein the obligation is an obligation to initiate a payment in exchange of a quantity of a tradable instrument received on a date.
4. A computer implemented method comprising:
receiving an information set from an entity for carrying out a trade in a tradable instrument, the information set comprising at least one attribute of an offer made by the entity;

identifying at least one trade type amongst a plurality of trade types based on the information set; and
clearing the trade based on the trade type by at least computing a value of at least one obligation arising out of the trade.
5. The method as claimed in claim 4, wherein the information set comprises information associated with another entity involved in the trade.
6. The method as claimed in claim 4, wherein the identifying the trade type comprises comparing the at least one attribute with a predefined parameter.
I. The method as claimed in claim 6, wherein the at least one attribute is at Jeast one of a
trade date, an expiry date, a settlement date, an exchange, a clearing house, a central
security depository, a tradable instrument, and a currency.
8. The method as claimed in claim 4; wherein the first entity is an external trade source.
9. The method as claimed in claim 4, wherein the trade type is one of a cash type and a derivatives type.
10. The method as claimed in claim 4, wherein the net value is one of a settlement value and a position value.
11. The method as claimed in claim 10, wherein the position value further comprises one
of a futures position, an options position, a swap position, and a premium settlement value.
12. The method as claimed in claim 4 further comprising determining existence of a netting level identification (ID) for the one or more attributes and adding the net value to the netting level ID, wherein a netting level is indicative of a level of computing of the net value.

13. The method as claimed in claim 4 comprises creating a new netting level ID for one or more groups of attributes.
14. A computer readable media for storing computer implemented instructions, said instructions when executed perform the acts comprising:
receiving an information set from an entity for carrying out a trade in a tradable instrument, the information set comprises at least one attribute of an offer made by the entity;
identifying at least one trade type amongst a plurality of trade types based on the information set; and
clearing the trade based on the trade type by at least computing a value of at least one obligation arising out of the trade.