WO2014158092A1

WO2014158092A1 - A method for carrying out a trade transaction and a system for carrying out the method

Info

Publication number: WO2014158092A1
Application number: PCT/SG2014/000137
Authority: WO
Inventors: R. V. Selvam
Original assignee: Singapore Infotech Pte Ltd
Priority date: 2013-03-28
Filing date: 2014-03-20
Publication date: 2014-10-02
Also published as: SG2013023627A

Abstract

An aspect of the present invention provides a method including receiving tender data from a tendering party via a computer network, storing the tender data in a database, receiving a confirmation signal from an accepting party thereby indicating an acceptance of a deal between the tendering party and the accepting party based on the tender data, retrieving the tender data of the confirmed deal from the database, generating a first draft contract for the tendering party based on at least the tender data of the confirmed deal, and generating a second draft contract for the accepting party based on at least the tender data of the confirmed deal, and another aspect of the present invention provides a system for carrying out the method.

Description

A METHOD FOR CARRYING OUT A TRADE TRANSACTION AND A SYSTEM

FOR CARRYING OUT THE METHOD

Technical Field

[0001] The present invention relates to a method for carrying out a trade transaction, for example, a method for carrying an end to end trade transaction and a system for carrying out the method.

Background

[0002] Organizations today are mostly using manual batch processes and systems located locally in trade transactions that are, incomplete, cumbersome and inefficient to conduct. With the advent of internet and cloud technologies, businesses are beginning to use multiple tools and softwares to improve efficiency and productivity. However, trade documentation and trade finance are probably the least developed sectors of trading, thereby making the whole process cumbersome, time consuming, inefficient, and prone to error and fraud.

[0003] A trade transaction starts when a party submits a tender, e.g. a buyer posts a bid or a seller posts an offer, for a given product. The parties, i.e. buyer and seller, then negotiate before arriving at a final deal. Most of the time, the negotiation is done in person, over the phone or through email and a Deal Confirmation or Deal Recap is exchanged manually or by email between the two parties. This Deal Confirmation/Deal Recap essentially captures all the main terms and the critical parameters of the deal e.g. product description, product specification, sale/delivery term (INCO Term), shipment timing, origin of the product, load port, discharge Port, payment terms, price, etc. The Sales and/or Purchase contracts are then manually drafted based on the deal confirmation, and exchanged via email/courier/fax. In the process, there are multiple risks like risk of gross manual errors, risk of differences in main terms between the Deal Recap and the Sales/Purchase contract and the risk of loss of critical documents. Also, due to its complexity, oftentimes Sales/Purchase contracts are never exchanged after the Deal Recap is established between the parties. In this regard, the whole trade cycle is completed in good faith or the Sales/Purchase contracts may be exchanged after the completion of shipment. Foreseeably, if a disagreement occurs between the parties, without a full-fledged legally binding Sales/Purchase contract, the parties may involve themselves in a legal tussle. Therefore, an exchange of a legally binding contract between the counter parties is an important step in the trade process.

[0004] Once the deal is confirmed, preferably with the exchange of the contracts, the parties would be obliged to fulfil the terms as spelled out in the contract.

[0005] Further, in the present scenario, if the mode of payment is through a Letter of Credit (LC), the seller sends the LC format and advising bank details to the buyer. The buyer then manually prepares the LC application which is sent to the LC opening bank (Buyer's Bank). At most times, the LC application fails to match the conditions of the LC format of the seller. The LC application drafted by the buyer is often not seen by the seller. After receiving the LC application, the LC opening bank generates the original LC and sends it to the advising bank (Seller's Bank). The whole process of LC application and issuance of LC is very time consuming and is prone to error. Due to the nature of the process, often times the LC would require amendments. Amendments are again an expensive, time consuming and prone to further errors.

[0006] Further, buyers or sellers (whoever is responsible for chartering the vessel) will search for an available vessel that suits their requirements. They contact the shipping company/ship broker to find a suitable vessel. Most of the communication including the negotiation of freight rate and other terms is done over the phone or via email. Once a suitable vessel is found, parties negotiate and conclude the detailed terms of vessel charter. The shipping company or the ship broker then generates the recap and sends it to the charterer (buyer/seller). The charterer then nominates the vessel to the counterparty and anyone else (terminals, etc) to check the suitability of the vessel for shipment. This is usually done through email and the process is inefficient, cumbersome and lacks visibility. Once the charterer gets a confirmation from the counterparty, the charterer confirms the vessel to the shipping company/ship broker. The shipping company/ship broker then generates the ship contract and sends the same to the charterer by courier.

[0007] Before the shipment takes place (before the vessel arrives for loading), the buyer/seller may contact a surveyor to inspect and certify the quantity, quality and other parameters of the product and shipment. The surveyor issues the certificates of quality, quantity, vessel cleanliness, etc after inspecting the goods and the vessel and these certificates are sent by courier to the concerned parties. This results in a lot of delay, error and a possible loss of the documents.

[0008] Once the goods are loaded onto the vessel, the shipping company issues the Bill of lading (BL) to the shipper/seller. The BL is a negotiable instrument and a critical document. The BL flows from the seller to the sellers bank, buyers bank and then to the buyer. This poses a risk of loss of the BL during transit. The buyer can collect the goods only upon presentation of original BL to the shipping company/shipping company's agent at the port of discharge. Also, often the original BLs fail to reach the buyer before the arrival of the vessel at the destination. Without the original BL the buyer cannot take possession of the goods. In this circumstance, the shipping company requests the charterer for a Letter of Indemnity (LOI) to be issued in its favour before releasing the cargo. The original LOI is generated by the buyer and sent to the seller who in turn issues a backing LOI to the shipping company via email. Upon receiving the LOI, the shipping company issues the Cargo Release Order to the buyer who can then use the same to collect the goods.

[0009] An object of the present invention is to overcome the abovementioned disadvantages and improve the efficiency in the present system.

Summary

[0010] In a first aspect of the present invention provides a method including receiving tender data from a tendering party via a computer network, storing the tender data in a database, receiving a confirmation signal from an accepting party indicating an acceptance of a deal between the tendering party and the accepting party based on the tender data, retrieving the tender data of the confirmed deal from the database, generating a first draft contract for the tendering party based on at least the tender data of the confirmed deal, and generating a second draft contract for the accepting party based on at least the tender data of the confirmed deal.

[0011] The method may further include receiving an agreement signal from the tendering party indicating a finalization of the first draft contract, receiving an agreement signal from the accepting party indicating a finalization of the second draft contract, forwarding a finalized first contract digitally to the accepting party, forwarding a finalized second contract digitally to the tendering party, receiving an endorsement signal from the accepting party indicating an endorsement of the finalized first contract; receiving an endorsement signal from the tendering party indicating an endorsement of the finalized second contract; forwarding the endorsed first contract via the computer network to the tendering party; and forwarding the endorsed second contract via the computer network to the accepting party.

[0012] The tender data may include new data generated by the tendering party or accepting party or data modified from previous tenders.

[0013] The method may further include modifying the tender data by at least one of the tendering party or accepting party after receiving the tender data and before receiving the confirmation signal.

[0014] The modification of the tender data by at least one of the two parties may be tracked and highlighted to the other party.

[0015] The method may further include generating a deal confirmation upon receiving the confirmation signal and forwarding the deal confirmation to the tendering party and the accepting party.

[0016] At least one of the first or second draft contract may be generated based on one or more predefined format or a new user defined format.

[0017] The method may further include receiving modification of at least one of the first draft contract or the second draft contract before forwarding the finalized first and second contracts to the tendering party and accepting party respectively.

[0018] The modification of the first draft contract or second draft contract by the respective parties may be tracked and highlighted to the other party.

[0019] The method may further include digitally signing and stamping the finalized first contract by the tendering party before forwarding the finalized first contract to the accepting party.

[0020] The method may further include digitally signing and stamping the finalized second contract by the accepting party before forwarding the finalized second contract to the tendering party.

[0021 ] The tendering party may include a buyer and the accepting party includes a seller. [0022] The method may further include generating a Letter of Credit format by the accepting party, forwarding the Letter of Credit format to the tendering party by the accepting party, generating a Letter of Credit application by the tendering party based on data from at least one of the following: the first contract, second contract and or Letter of Credit format.

[0023] The method may further include forwarding the Letter of Credit application to the accepting party, receiving an endorsement signal indicating an acceptance of the Letter of Credit application from the accepting party, and forwarding the Letter of Credit Application to various banks generating a Letter of Credit based on the endorsed Letter of Credit application.

[0024] The method may further include modifying the Letter of Credit application by at least one of the tendering party or the accepting party after forwarding the Letter of Credit application to the accepting party.

[0025] The endorsed Letter of Credit application may be forwarded to an opening bank engaged by the tendering party, wherein the original Letter of Credit is generated by the opening bank based on the Letter of Credit application, the method may further include modifying of the endorsed Letter of Credit application by at least one of the tendering party or the opening bank prior to generating the Letter of Credit.

[0026] The modified endorsed Letter of Credit application may be forwarded to the accepting party for consent prior to generating the Letter of Credit.

[0027] The method may further include generating a draft Letter of Credit based on the endorsed Letter of Credit application and forwarding the draft Letter of Credit to the tendering party prior to generating the Letter of Credit.

[0028] The draft Letter of Credit may be forwarded to the accepting party by the tendering party.

[0029] The method may further include modifying the draft Letter of Credit by at least one of the tendering party or the accepting party.

[0030] The method may further include receiving an approval signal from the tendering party and generating the Letter of Credit based on the approved draft Letter of Credit. [0031] The Letter of Credit may be generated by an opening bank representing the tendering party.

[0032] The Letter of Credit may be forwarded by the opening bank to an advising bank representing the accepting party.

[0033] The Letter of Credit may be forwarded by the advising bank to the accepting party.

[0034] The method may further include receiving cargo data from a chartering party via the network, receiving a request signal from the chartering party requesting for at least quotation data and vessel data from at least one shipping party, receiving at least the quotation data and vessel data from a shipping party based on the cargo data via the network, receiving an agreement signal from the chartering party indicating an agreement with at least the quotation data and the vessel data, generating a shipping contract based on at least the quotation data, receiving an agreement signal from the chartering party indicating an agreement with the shipping contract, and generating a Bill of Lading document based on at least the cargo data, vessel data and shipping contract data.

[0035] The method may further include receiving at least cargo data from at least one chartering party.

[0036] The method may further include receiving at least vessel data from at least one shipping party, said vessel data visible to the chartering party.

[0037] The method may further include receiving a search query from the chartering party to search for a shipping party.

[0038] The method may further include generating a recap document based on at least the cargo data, quotation data, shipping data and vessel data upon receiving the agreement signal.

[0039] The method may further include forwarding the recap document to the chartering party.

[0040] The method may further include forwarding the vessel data to a counter party after receiving the agreement signal from the chartering party in the form of a vessel nomination.

[0041] The method may further include receiving a confirmation signal from the chartering party and countering party confirming the vessel data. [0042] The method may further include modifying the vessel data before receiving the confirmation signal.

[0043] The method may further include generating a shipping contract by the shipping party upon receiving the agreement signal from the chartering party.

[0044] The method may further include digitally signing and stamping the shipping contract by the shipping party and forwarding the signed and stamped shipping contract to the chartering party over the computer network.

[0045] The method may further include digitally signing the shipping contract by the chartering party and forwarding the signed shipping contract to the shipping party.

[0046] The chartering party may include one of the tendering party and the accepting party, and the counter party may include the other of the tendering party and accepting party.

[0047] The method may further include receiving a request from a tendering/accepting party for at least one certificate and generating at least one certificate by the surveyor.

[0048] Another aspect of the present invention provides a system having a receiving module configured to receive tender data from a tendering party via a computer network and a database configured to store the tender data. The receiving module is configured to receive a confirmation signal from an accepting party indicating an acceptance of a deal between the tendering party and the accepting party based on the tender data. The retrieving module is configured to retrieve the tender data of the confirmed deal from the database. Further, the system has a generating module configured to generate a first draft contract for the tendering party based on at least the tender data of the confirmed deal and a second draft contract for the accepting party based on at least the tender data of the confirmed deal.

[0049] The system may further include a forwarding module configured to forward a finalized first contract digitally to the accepting party. The forwarding module may be configured to forward a finalized second contract digitally to the tendering party such that the receiving module may be configured to receive an agreement signal from the tendering party indicating the finalization of the first draft contract. The receiving module may be configured to receive an agreement signal from the accepting party indicating the finalization of the second draft contract. The receiving module may be configured to receive an endorsement signal from the accepting party indicating the endorsement of the first contract. The receiving module may be configured to receive an endorsement signal from the tendering party indicating the endorsement the second contract. The forwarding module may be configured to forward the endorsed first contract via the computer network to the tendering party and may be configured to forward the endorsed second contract via the computer network to the accepting party.

Brief Description of Drawings

[0050] Fig. 1 shows a schematic diagram of an exemplary trading system having a trade and contract management module, a trade finance management module, a trade operations management module, a trade document management module and a resources management module;

[0051] Fig. 1A shows schematic diagram of an exemplary system suitable for the trading system in Fig. 1;

[0052] Fig. 2 shows a schematic diagram of a trade managing method of a trade and contract management module in Fig. 1;

[0053] Fig. 3 shows a flow diagram of a trade managing method using the trade and contract management module in Fig. 1 ;

[0054] Fig. 4 shows a flow diagram of a trade finance managing method of a trade finance management module in Fig. 1 ;

[0055] Fig. 5 shows a flow diagram of another aspect of the trade finance managing method of Fig. 4;

[0056] Fig. 6 shows a flow diagram of another aspect of the trade finance managing method of Fig. 4;

[0057] Fig. 7 shows a flow diagram of a trade operations managing method of the trade operations management modules of the trading system in Fig. 1 ;

[0058] Fig. 7A shows a flow diagram of another aspect of the trade operations managing method of Fig. 7; [0059] Fig. 8 shows a flow diagram of another aspect of the trade operations managing method of Fig. 7;

[0060] Fig. 9 shows a flow diagram of another aspect of the trade operations managing method of Fig. 7;

[0061] Fig. 9 A shows a flow diagram of a trade document managing method of a trade document management module in Fig. 1;

[0062] Fig. 10 shows a flow diagram of a resource managing method of a resources management module in Fig. 1 ; and

[0063] Fig. 11 shows the trading system in Fig. 1 having interaction with external systems and users/customers.

Detailed Description

[0064] The present invention provides an exemplary trading system 100 and trading method 110 for carrying out trading activities or operation.

[0065] Fig. 1 shows a schematic diagram of a exemplary trading system 100. Trading system 100 includes a trade and contract management module 1000 and may include a trade finance management module 2000, a trade operation management module 3000, trade document management module 4000, and a resource management module 5000. Trading system 100 may also be known as a platform or integrated system. Trading system 100 provides a trading method 110 which includes sub-methods like a trade managing method 1010, a trade finance managing method 2010 and a trade operation managing method 30 0.

[0066] Trade and Contract Management Module

[0067] Fig. 1A shows a system 500 having a receiving module 510 configured to receive tender data from a tendering party 10 via a computer network, a database 520 configured to store the tender data, the receiving module 510 configured to receive a confirmation signal from an accepting party 20 indicating an acceptance of a deal between the tendering party 10 and the accepting party 20 based on the tender data, a retrieving module 530 configured to retrieve the tender data of the confirmed deal from the database 520, and a generating module 540 configured to generate a first draft contract for the tendering party 10 based on at least the tender data of the confirmed deal and a second draft contract for the accepting party 20 based on at least the tender data of the confirmed deal.

[0068] Fig. 2 shows an exemplary trade managing method 110 executable by the trade and contract management module 1000. Trade managing method 110 includes, receiving tender data from a tendering party 10 via the computer network in 112 (1012T,1012A), storing the tender data in the database 114, receiving a confirmation signal from an accepting party 20 indicating an acceptance of a deal between the tendering party 10 and the accepting party 20 based on the tender data in 116, retrieving the tender data of the confirmed deal from the database in 118, generating a first draft contract for the tendering party 10 based on at least the tender data of the confirmed deal in 120 (1042T), and generating a second draft contract for the accepting party 20 based on at least the tender data of the confirmed deal in 122 (1052A).

[0069] As shown in Fig. 3, trade and contract management module 1000 provides the functionality of posting tender data on the trading system 100. For example, the tendering party 10 may be a buyer 12 and the buyer 12 posts a bid in the trading system 100 (refer to 1012T). In this example, the bid may be visible to an accepting party 20 who may be a seller 22 (1012A). In another example, the tendering party 10 may be a seller 22 and the seller 22 posts an offer in the trading system 100 (1022 A). In this later example, the offer may be visible to an accepting party 20 (1022T) who, in this case, may be a buyer 12. Tender data may include a bid posted by a buyer or an offer posted by a seller.

[0070] Accepting party 20 would send a confirmation signal to the tendering party 10 via the trading system 100 if the accepting party 20 accepts tender data (1024A,1024T). Once the accepting party 20 confirms the tender data by sending a confirmation signal to the trading system 100 indicating an acceptance of the tender data, the tender data may be retrieved from the database by the tendering party 10 and the accepting party 20 and they may generate the first draft contract and the second draft contract respectively. Confirmation signal may be sent from the tendering party 0 and the accepting party 20 respectively to confirm the acceptance of the first and second draft contract (1044T,1044A).

[0071] Trade managing method 110 may further include generating a deal confirmation upon receiving the confirmation signal and forwarding the deal confirmation to the tendering party 10 and the accepting party 20. A deal confirmation may be a digital document which captures all the main terms and the critical parameters of the deal. A deal confirmation may be automatically generated by the trading system 100 when the deal has been confirmed, capturing all data, e.g. terms and conditions, mutually agreed by both the tendering party 10 and the accepting party 20 and the deal confirmation may be sent automatically to both the tendering party 10 and the accepting party 20 (1032A,1032T). The first and second draft contracts may be generated after receiving the deal confirmation from the trading system 100.

[0072] Referring to Fig. 3, in the above example wherein the tendering party 10 may be a buyer 12 and the accepting party 20 may be a seller 22, the first draft contract may be a draft contract of purchase (COP) generated by the buyer 12 and forwarded by the buyer 12 (1042T) to the seller 22 (1042A) via the trading system 100 and the second draft contract may be a draft contract of sale (COS) generated by the seller 22 and forwarded by the seller 22 (1052A) to the buyer 12 (1052T) via the trading system 100. In the example, wherein the tendering party 10 may be a seller 22 and the accepting party 20 may be a buyer 12, the first draft contract may be a COS generated by the seller 22 and forwarded to the buyer 12 via the trading system 100 (1052 A) and the second draft contract may be a COP generated by buyer 12 and forwarded to the seller 22 via the trading system 100 (1042T).

[0073] The first and second draft contracts may be generated using information from the deal confirmation thereby eliminating time wastage and the possibility of errors. The first and second draft contracts may be automatically generated. At least one of the first or second draft contract may be generated based on one or more predefined formats or a new user defined format. The first and second draft contracts may be generated using predefined formats available in the trading system 100 or new user defined formats may be generated for the first and second draft contracts. ew user defined formats may be saved for future use.

[0074] The trading system 100 may keep track of the changes made by one party and highlights it to the other party.

[0075] Trade managing method 110 may further include receiving an agreement signal from the tendering party to indicate a finalization of the first draft contract, receiving an agreement signal from the accepting party to indicate a finalization of the second draft contract (1044A/1054A, 1044T/1054T), forwarding a finalized first contract digitally to the accepting party (1062T,1062A), forwarding a finalized second contract digitally to the tendering party (1072A,1072T), receiving an endorsement signal from the accepting party indicating an endorsement of the finalized first contract, receiving an endorsement signal from the tendering party indicating an endorsement of the finalized second contract, forwarding the endorsed first contract via the computer network to the tendering party (1064A,1064T), and forwarding the endorsed second contract via the computer network to the accepting party (1074T,1074A).

[0076] The first draft contract may be reviewed by the accepting party 20 and the second draft contract may be reviewed by the tendering party 10. After the first and second draft contracts have been reviewed and confirmed by the accepting party 20 and tendering party 10 respectively, the accepting party 20 and the tendering party 10 may each confirm the draft contracts respectively by each sending an agreement signal to the trade and contract management module 110 to indicate their agreement of the contracts thus finalizing the first and second draft contracts (1044A/1054A, 1044T/1054T). As shown in Fig. 3, seller 22 finalizes the draft COP by sending the agreement signal to the trade and contract management module 1000 (1044A,1054A). Buyer 12 finalizes the draft COS by sending the agreement signal to the trade and contract management module 1000 (1044T, 1054T).

[0077] After both tendering party 10 and accepting party 20 mutually agree to the contents of the first and second draft contracts, a finalized first contract and a finalized second contract may be generated. Finalized first contract may be an original COP and finalized second contract may be an original COS. The finalised first and second contracts may then be digitally signed, stamped and exchanged by both the parties. Finalized first contract may be generated by the tendering party 10 and finalized second contract may be generated by accepting party 20 after receiving the agreement signals confirming and finalizing the first and second draft contracts.

[0078] Trade managing method 110 may further include affixing a digital signature and digital stamp by the tendering party acknowledging the finalized first contract before forwarding the finalized first contract to the accepting party (1062T,1062A) as shown in Fig. 3. Trade managing method 110 may further include affixing a digital signature arid digital stamp by the accepting party for the finalized second contract before forwarding the finalized second contract to the tendering party (1072A,1072T).

[0079] trade and contract management module 1 10 may provide a digital signature and stamp function for a party to affix a digital signature and stamp onto a digital document , when the party approves of the document. The original COP or COS may be digitally signed and stamped by a generating party, i.e. tendering party 10 or accepting party 20 in the trading system 100 or platform and it is then exchanged with the counterparty, i.e. accepting party 20 or tendering party 10, who then digitally signs, stamps and sends it back to the generating party. As shown in Fig. 3, buyer 12 may sign and stamp the original COP and forward the original signed and stamped COP to the seller 22 (1062T,1062A) for the seller 22 to sign. Seller 22 may sign the original COP and return the original COP to the buyer 12 (1064A,1064T). Vice versa, the seller 22 may sign and stamp the original COS and forward the original signed and stamped COS to the buyer 12 (1072A,1072T) for the buyer 12 to sign. Buyer 12 may sign and stamp the original COS and return the original COS to the seller 12 (1074T,1074A).

[0080] Trading system 100 may also provide an option in the trading system 100 for the tendering party 10 and/or accepting party 20 to reconcile the contract clauses of the original COP and COS if there is any disparity or conflict in those clauses ( 1082T, 1082 A).

[0081] Trade managing method 110 may include modifying the tender data by at least one of the tendering party 10 or accepting party 20 after receiving the tender data and before receiving the confirmation signal. Tender data, e.g. offers and bids, may be countered and negotiated by a counterparty, e.g. the accepting party 20. Tendering party 10 and accepting party 20 may negotiate an offer/bid before arriving at a confirmed deal. When this happens, the tendering party 10 and the accepting party 20 may counter the tender data and negotiate (1014A,1027T). Therefore, the tender data may be modified according to the negotiation after being received and before being confirmed by the tendering party 10 and accepting party 20.

[0082] Modification of the tender data by at least one of the two parties may be tracked and highlighted to the other party. Once tender data, e.g. an offer or a bid, is countered, the trading system 100 may keep track of the changes made by the counterparty and highlight the changes to the other party. Trade managing method 110 may include receiving modification of at least one of the first contract or the second contract before forwarding the finalized first and second contracts to the tendering party and accepting party respectively. The first and second draft contracts may be modified by counterparties, i.e. tendering party 10 or accepting party 20, before being accepted and confirmed (1044T,1044A). The provision of draft contracts allows the two parties involved in the deal to make changes and agree upon all the terms and conditions before finalizing the first and second draft contracts. The first and second draft contracts may be modified by both the counterparties to accurately reflect the terms mutually agreed upon. Modification of the first or second contract by tendering party 10 or accepting party 20 may be tracked and highlighted to the other party.

[0083] Tender data may include new data generated by the tendering party 10 or accepting party 20 or data modified from previous tenders. Tender data may be posted in two ways. In the first way, a previously posted tender data may be retrieved and modifications may be made before posting as new tender data. In the second way, a fresh or new data may be created and by entering all the necessary details into the trading system 100 before posting in the trading system 100. Using previous tender data (as in the first way) and making amendments to it before posting the amended tender data as new tender data eliminates wastage of time in recreating new tender data therefore saving a lot of time as the tendering party 10 or accepting party 20 need not re-enter all the details or data.

[0084] Tender data, i.e. offer or bid, may be posted to the open market or to a selected group of pre-approved counterparties and/or middle parti es/brokers. Accepting parties, e.g. buyers or sellers, may view the "open" tender data and may either confirm or counter the tender data.

[0085] Tender data may be posted to the "open market" for all to view and/or to pre- approved buyers/sellers and/or to middle parties brokers. Buyers and sellers can also choose to be anonymous to the counterparty or to the middle parties/brokers while posting tender data.

[0086] Trading system 100 may provide modification of deal conditions when countering tender data, i.e. offers and bids. When tender data is countered, the trade and contract management module 1000 tracks the changes and highlights the changes made by one counter party to the other. The trade and contract management module 1000 may also provide the functionality for tendering party 10 and/or accepting party 20 to directly exchange deal conditions in the form of deal confirmation (1032T,1032A) without going through various steps of posting tender data (bids/offers) and countering, negotiating on the tender data on the trading system 100. This is akin to the deals being negotiated and concluded on the phone or in person in real business time and still be able to use other functionalities in the system.

[0087] In the event that a broker 32, e.g. a sales broker, is involved in the deal, the tendering party 10, accepting party 20 and the middle party 32 may begin a trading transaction on the trading system 100 by generating and transmitting a deal confirmation (1034SB in Fig. 3). The broker 32 may use the trading system 100 to view the tender data posted by the tendering party 10 and the accepting party 20. The middle party 32 may then counter the tender data with the tendering party 10 or the accepting party 20 (1016SB,1026SB) on behalf of a counterparty. In a scenario where a middle party 32 finalizes a deal, the middle party 32 may generate the deal confirmation and transmit the deal confirmation to the tendering party 10 and accepting party 20 ( 1034T,1034A). As shown in Fig. 3, the middle party 32 may negotiate and/or finalize the tender data using the trade and contract management module 1000 (1026T,1026A,1016SB,1026SB).

[0088] The trading system 100, via the trade managing method 110, introduces the concept of draft contracts so that buyers and sellers can exchange and modify detailed terms and conditions of the contract other than the main terms of the deal which have already been agreed to by both the parties by way of deal confirmation before generating the original contract. The benefit of draft contracts is that both the parties are allowed to agree to all the terms and conditions of the draft contract before the original contract is generated and exchanged for endorsement. In this way, the efficiency of the trading process is improved and the need for changes in the original contract is minimised or eliminated. The transfer of documents on the trading system 100 may be immediate thereby saving time and minimising or eliminating the risk of loss of documents during transit in the current way of trading.

[0089] trade and contract management module 1000 may allow buyer 12 and seller 22 to search for an active counterparty using a Search by Criteria function. A search can be conducted using multiple search criteria such as Product, Load Port, Discharge Port, Country, recent activity, etc.

[0090] Trade Finance Management Module

[0091] Trading system 100 may further include a trade finance management module 2000. Trade finance management module 2000 may include a trade finance managing method 2010.

[0092] Trade finance managing method 2010 may include generating a Letter of Credit (LC) format by the accepting party 20, forwarding the Letter of Credit format to the tendering party 10, generating a Letter of Credit application by the tendering party 10 based on data from at least one of the following: the COS, COP and/or the Letter of Credit format. [0093] If the mode of payment under the contract is through a Letter of Credit (LC), then the tendering party 10 may then proceed to open an LC with an LC opening bank 14.

[0094] Conventionally, the tendering party 10 for opening an LC may be the buyer 12. Therefore, the term, buyer 12, would be used instead of the tendering party 10 when explaining the trade finance management method 2010. Consequently, the accepting party 20 would be the seller 22. Opening bank 14 may also be known as the buyer's bank as it receives instructions from and represents the buyer 12 or LC opening bank.

[0095] As shown in Fig. 4, seller 22 may send advising bank details and/or LC format with LC conditions acceptable to the seller 22 to the buyer 12 via the trading system 100 (2012A,2012T). A bank which advises the LC received from the LC opening bank to the seller and handles all aspects of that LC may be known as the advising bank, negotiating bank or the seller's bank.

[0096] Trade finance managing method 2010 may further include forwarding the Letter of Credit application to the accepting party 20 (2022T,2022A), receiving an endorsement signal indicating an endorsement or acceptance of the contents of the Letter of Credit application from the accepting party 20 (2024A,2024T), forwarding the Letter of Credit application by the tendering party 10 to the LC opening bank 14 (2032T,2032TB) and generating a Letter of Credit based on the endorsed Letter of Credit application.

[0097] Upon receiving the advising bank details and/or LC format, the buyer 12 may then proceed to generate an LC application and forward the LC application to the seller 22 for their review and consent (2022T,2022A). The LC application may be auto populated by the system with corresponding values for the given transaction from documents in the database including the deal confirmation, COS, COP and the LC format.

[0098] Seller 22 may review the LC application received from the buyer 12 and if the seller 22 is agreeable with the contents of the LC application, the seller 22 may endorse the LC application signifying the seller's acceptance to the contents of the LC application by sending an endorsement signal to the trading system 100 (2024A). Once the contents of the LC application is confirmed and accepted by the seller 22, buyer 12 may forward the confirmed LC application to the LC opening bank 14 (2032T,2032TB). The LC opening bank 14 can then proceed to generate the draft original LC based on the LC application. [0099] Once the endorsed Letter of Credit application is forwarded to an opening bank 14 engaged by the tendering party 10, the draft/original Letter of Credit may be generated by the opening bank 14 based on the Letter of Credit application.

[00100] Trade finance managing method 2010 may include a provision for modifying the Letter of Credit application by at least one of the tendering party 10 or the accepting party 20 after forwarding the Letter of Credit application to the accepting party 20 by the tendering party 10.

[00101] Buyer 12 may have the provision of modifying the LC application before forwarding the LC application to the opening bank 14 (2032T) if the buyer so wishes. If seller 22 wishes to modify the LC application when reviewing the LC application sent by the buyer 12, the trading system 100 allows seller 22 to modify the LC application before finalizing the LC application and confirming the LC application to the buyer 12. (2024T,2024A). Opening bank 14 may modify the LC application on parameters which do not conform to the banks rules and terms and conditions and forward the modified LC application to the buyer 12 for review (2034T,2164TB). Modifications may be highlighted to the other party, i.e. buyer 12, to allow easy review. Prior approval of the seller 22 to the contents of the LC application negates or minimises the need for amendments to the original LC once the original LC is issued.

[00102] Trade finance managing method 2010 may include modifying of the endorsed Letter of Credit application by at least one of the tendering party 10 (2034T) or the opening bank 14 (2164TB) prior to generating the Letter of Credit.

[00103] Opening bank 14, when it receives an LC application generated by the buyer 12 (2032T,2032TB), may scrutinize the application to check if the clauses in the application meets the requirements of the opening bank 14. Opening bank 14 may modify the LC application if required to ensure that the LC application meets the rules and regulations of the opening bank 14 (2164TB) and send the modified LC application back to the buyer 12 (2034T). On receiving a modified LC application from the opening bank 14, the buyer 12 may review the LC application and can either accept the modification or make further modifications to the LC application and send the LC application to the opening bank 14 (2034T,2164TB). This process can go on till both the buyer 12 and the LC opening bank 14 agree to the contents of the LC application. [00104] The modified Letter of Credit application may be forwarded to the seller 22 by the buyer 12 for consent prior to the buyer requesting the LC opening bank 14 for generating the Letter of Credit (2022T,2022A).

[00105] The buyer 12 may send the modified LC application received from the opening bank 14 to the seller 22 for approval before accepting the modifications made by the opening bank 14.

[00106] Trade finance managing method 2010 may further include generating a draft Letter of Credit by the LC opening bank 14 based on the endorsed Letter of Credit application sent by the tendering party 10 and forwarding the draft Letter of Credit to the tendering party 10 and seeking their acceptance prior to generating the original Letter of Credit (2142TB,2042T). Draft Letter of Credit may be forwarded to the accepting party 20 by the tendering party 10 (2044T,2084A). Trade finance managing method 2010 may further include modifying the draft Letter of Credit by at least one of the tendering party 10 or the accepting party 20 (2046A,2046T).

[00107] Once the LC application is confirmed and accepted by the seller 22 (2024A), buyer 12 (2046T) and the opening bank 14 (2164TB), the LC opening bank may proceed to generate the draft LC. The draft LC may be forwarded by the opening bank 14 to the buyer 12 (2142TB) which maybe further forwarded to the seller 22 for review (2044T,2084A). The draft LC may either be confirmed or modified by the buyer 12 (2052TB). The buyer 12 may also send the draft LC to the seller 22 (2044T,2084A) to obtain approval from the seller 22 before confirming or modifying the draft LC with the opening bank 14. Draft LC generated may be modified by the buyer 12 and seller 22 till mutual agreement is reached (2046A,2046T). By allowing modification before generating the original LC reduces the need for amendments at a later stage.. Modification to the draft LC may be made by the opening bank 14 and forwarded to the buyer 12 for review/approval (2052TB,2052T). Similarly, buyer 12 may modify the draft LC and forward the modified draft LC to the opening bank 14 (2052T,2052TB).

[00108] Trade finance managing method 2010 may include receiving an approval signal from the tendering party 10 and generating the original Letter of Credit based on the approved draft Letter of Credit, The original Letter of Credit may be generated by the opening bank 14 representing the tendering party 10. The original Letter of Credit may be forwarded by the opening bank 14 to an advising bank 24 representing the accepting party 20 (2162TB,2062AB). The original Letter of Credit may be forwarded/advised by the advising bank 24 to the accepting party 20. A copy of the original LC maybe forwarded by the LC opening bank 14 to the tendering party 10.

[00109] Once the buyer 12 confirms the draft LC, buyer 12 may request the opening bank 14 to issue the original LC. The LC opening bank 14 may then generate and transmit the original LC either to the advising bank 24 (seller's bank) (2162TB,2062AB) or to the seller 22 directly depending upon what has been requested in the LC application. Advising bank 24 may generate an original LC advice and forward the advice to the seller 22 along with the original LC (2062AB,2064A).

[00110] As mentioned, opening bank 14 may receive the LC application generated by the buyer 12 and may have the option of generating a draft LC. Draft LC may be forwarded to the buyer 12 for review (2142TB,2042T). Buyer 12 may send the draft LC to the seller 22 for review (2044T,2044A). Trade finance managing method 2010 may provide the buyer 12 and seller 22 a chance to modify and align the format of the draft LC to meet their requirements (2046T,2046A). Before an original LC may be generated, a confirmation or agreement signal may be received by all the parties on the draft, i.e. buyer 12 (2052T), seller 22 (2046 A) and opening bank 14 (2052TB). In this way, the visibility of the draft LC may be improved and the possibility of errors in the original LC may be reduced. The original LC may then be sent by the opening bank 14 (2162TB) to the advising bank 24 (2062 AB) or seller 22 (2064A) depending on what is requested in the LC application and a copy of the original LC may be sent to the buyer 12 (2063T).

[00111] Even after the issuance of original LC, the buyer 12 or seller 22 may still be able to request for amendments to the original LC if the buyer 12 or seller 22 is not satisfied with the clauses in the original LC issued or to reflect any other change which the buyer 12 or seller 22 wishes to enter into the original LC. The seller 22 may send an amendment request to the buyer 12 (2072A,2072T). The amendment request may be modified by the buyer 12. Buyer 12 may then send the modified amendment request to the seller 22 (2074T,2074A). Seller 22 may send a confirmation of the amendment request, indicating an agreement with the contents of the amendment request to the buyer 12 (2074A,2074T). On agreement with the seller 22 on the amendment request, the buyer 12 may send the amendment request to the LC opening bank 14 (2082T,2082TB). Amendments to the original LC may then be modified and finalized between the buyer 12 and the opening bank 14 (2084T,2184TB). Buyer 12 may then send the final amendment request to the opening bank (2084T,2184TB). The opening bank 14 may then generate and issue the original amendment. The original amendment may be sent to the advising bank 24 (seller's bank) (2192TB,2092AB) and thereafter advised to the seller by the advising bank 24.(2104AB) or advised directly to the seller 22 (2094A) by the LC opening bank 24 (2106TB) depending upon what has been requested in the LC application.

[00112] As mentioned, the buyer 12 or seller 22 may request for amendments to the original LC even after the generation of original LC. If the seller 22 requires an amendment to the original LC, seller 22 may send the amendment request to the buyer 12 (2072A,2072T). Buyer 12 and seller 14 may modify the contents of the amendment request before arriving at consensus or a confirmation on the contents of the amendment request (2074T,2074A). Once the amendment request is confirmed between the buyer 12 and seller 22, the buyer 12 may then send the final amendment request to the opening bank 14 (2082T,2082TB). Buyer 12 and the opening bank 14 may modify the contents of the amendment request (2184TB,2084T). Upon confirmation with the opening bank 14, the buyer 12 has the option of re-checking with the seller 22 (2086T,2086A) before giving a final confirmation to the opening bank 14 (2088T,2088TB). On receiving the final confirmation from the buyer 12, the LC opening bank 14 may generate the original amendment and transmit it to the seller 14 (2192TB,2094A) or the advising bank 24 (2192TB ,2092 AB) depending upon what has been requested in the LC application. A copy of the amendment may be sent to the buyer 12 (2093T). The advising bank 24 may advise the amendment to the seller 22 (2094AB,2094A).

[00113] At a later stage, the seller 22 may use the trading system 100 to collect all the trade documents, as per LC conditions (2102 A) These trade documents may then be presented by the seller 22 to the advising bank 24 (2102 A) or a negotiating bank which maybe the advising bank 24 or the LC opening bank 14 as required (2102TB). Seller 22 may instruct the advising bank 24 or LC opening bank 14 to either check the documents for discrepancies or directly transmit the documents to the opening bank 14. The checking of the documents for discrepancies may be done automatically by the trading system 100. The trade finance management method 2010 may check each document for discrepancies using data from the requirements specified in the original LC. The negotiating bank which maybe the advising bank 24 or any other bank to which the documents have been presented for negotiation by the seller 22 may check the trade documents against the requirements specified in the original LC. If it finds any discrepancies, it may report the discrepancies to the seller 22. If the advising bank 24 checks the documents and find any discrepancies, the advising bank may report the discrepancies to the seller 22 (2104AB,2104A). Seller 22 may then if possible rectify the discrepancies and re-present the documents to the advising bank 24. If it is not possible for the seller 22 to rectify the discrepancies in the documents, the seller 22 may request the negotiating bank which maybe the advising bank 24 or any other bank to forward the documents to the LC opening bank 14 by either mentioning or not mentioning the discrepancies. If the presentation of the trade documents by the seller 22 to the negotiating bank is credit conforming, the negotiating bank may then notify the LC opening bank 14 about credit conforming documents having been taken up and forward the full set of documents to the LC opening bank 14 as required under the terms of the original LC. The LC opening bank 14, on receiving the documents from the advising bank 24, may check the documents for discrepancies. If the LC opening bank 14 finds the documents to be credit conforming, it may notify the tendering party 10 about the same and forward the original documents to the tendering part 10 (2110TB,2110T). If the LC opening bank 14 on receiving the documents from the advising bank 24 and checking the documents for discrepancies finds discrepancies in the documents, the LC opening bank 14 may notify the negotiating bank (2106AB) and the tendering party 10 (2106T) about the discrepancies and may notify the negotiating bank that the documents are being held at the risk and disposal of the negotiating bank. It may simultaneously advise the tendering party 10 about the discrepancies and take the tendering party 10 response on whether the discrepancies are acceptable or if the tendering party 10 wants to reject the documents. If the tendering party 10 sends a confirmation signal indicating the acceptance of the advised discrepancies, the LC opening bank 14 may then forward the original documents with the discrepancies to the tendering party 10. If the tendering party 10 sends a confirmation signal indicating the rejection of documents, the LC opening bank 14 may then forward the documents back to the negotiating bank which maybe the advising bank 24 or any other bank along with the notice of rejection. The negotiating bank may then forward the documents back to the seller along with the notice of rejection.

[00114] As mentioned, seller 22 may use the trading system 100 to prepare all the trade documents as per LC conditions. Trading system 100 may allow the seller 22 to select the required documents from the database 520 (shown in Fig. 1A) and transmit them to the advising bank 24 or the opening bank 14 or any other negotiating bank as may be chosen by the seller in one lot (2102A,2102AB).

[00115] On receiving the advice of discrepancies from the opening bank 14, buyer 12 may choose to accept or reject the documents (2108T,2108TB). If the buyer 12 accepts the documents, the opening bank 14 may release all the original documents to the buyer 12 (2110TB,2110T) after due process by the LC opening bank 14 to fulfil the conditions of the LC between the LC opening bank 14 and the buyer 12. If the buyer 12 rejects the documents, the opening bank 14 may send the rejection notice to the negotiating bank which maybe the advising bank 24 or any other bank along with the original documents and advice of rejection stipulating the reasons for rejection. The negotiating bank which maybe the advising bank 24 may then forward the original documents to the seller 22 along with the notice of rejection.

[00116] There may be different types of LCs and payment methods, including Standby LC, Documentary LC and Transferable LC, that may be supported by the trade finance management module 2000. Trading system 100 may also provide functionalities for other payment modes in a trade transaction including Open Account/Direct Payment, Documents against Acceptance (DA), Documents against Payment (DP) and Advance Payment.

[00117] Referring to Fig. 5, under the Open Account/Direct Payment, the buyer 12 may send the documentary instructions to the seller 22 (2112T,2112A). Seller 22 may modify or confirm the documentary instructions. The modification of the documentary instructions may go back and forth between the buyer 12 and seller 22 until both buyer 12 and seller 22 can agree and confirm the documentary instructions (2114T,2114A). At a later stage, the seller 22 may gather all the trade documents related to the transaction as per the documentary instructions and send them to the buyer 12 directly via the trading system 100 (2114A,2122T).

[00118] As mentioned, the trading system 100 may also support Open Account/Direct Payment transactions where the banks are not involved as far as the movement of documents are concerned and the buyer 12 and seller 22 may directly interact with each other to exchange documentary instructions and documents.

[00119] As shown in Fig. 6, under DA/DP, similar to the steps in Open account/Direct Payment transactions, buyer 12 may send documentary instructions to seller 22 (2212T,2212A). Buyer 12 and seller 22 may modify the documentary instructions until they arrive at a mutual conclusion on the documentary instructions (2214T,2214A). Seller 22 may collect all the trade documents from the database and send the documents to the sellers bank 24 (2222A,2222AB) with clear instructions about document handling, specifying whether the documents have to be sent to the buyers bank 14 under DA or DP. Banks usually deal in these documents under DA or DP only to the extent of handling the documents without taking responsibility for payment as in some cases under the LC. .

[00120] As mentioned, trading system 100 may also support DA/DP transactions in which banks are involved to the limited extent of handling documents without being responsible for payment. Buyer 12 and seller 22 may modify and confirm on the documentary instructions (2214T,2214A). Seller 22 may generate all the trade documents to conform to the documentary instructions and send all the documents to the seller bank 26 (2222A,2222AB). Seller bank 26 may cross check the documents for discrepancies and if any discrepancies are found, the seller bank 26 may advise the same to the seller 22. The checking of the documents for discrepancies may be done automatically by the trading system 100. The trade finance management method 2010 may check each document for discrepancies using data from the requirements specified in the documentary instructions. Seller 22 may then if possible rectify those discrepancies and re-present the documents without discrepancies to the seller bank 26 and may direct the seller bank 26 to send the documents under DA or DP to the buyer bank 16. (2223AB,2222TB). Buyer bank 16 may cross check the documents for discrepancies among themselves and send the advice of discrepancies to the buyer 12 (2224TB ,2224T) along with the request for instructions from the buyer 12 for handling the documents, i.e whether the documents have to be accepted or rejected. If the buyer 12 accepts the documents with/without discrepancies, then the buyer bank 16 may release the original documents to the buyer 12 against payment if it is under DP and an undertaking to pay at a future date if it is under DA. If the buyer 12 rejects the documents, the buyer bank 16 may send the documents along with the notice of rejection to the seller bank 26 who may then forward the same to the seller 22. Trade finance management module 2000 of the trading system 100 introduces the concept of draft LC. Right from the initial stage of LC application, seller 22 and buyer 12 may have substantial or complete visibility of the LC terms and conditions. Opening bank 14 may also be able generate a draft LC which can be reviewed by the buyer 12 and seller 22 before proceeding to issue the original LC. Such a method helps to eliminate or minimise the need for amendments or minimise amendment.

[00121] In addition, trade finance management module 2000 may provide automatic checking of the discrepancies of the documents with respect to the LC conditions or documentary instructions thereby ensuring elimination or minimising of mistakes due to human error and completion of specific tasks within a specific timeframe.

[00122] In few cases, the seller bank 26 and the buyer bank 16 may be the same bank.

[00123] Trade Operations Management Module

[00124] Trading system 100 may include a trade operations management module 3000. Trade Operations management module 3000 may involve tasks that are performed with respect to physical shipment/actual movement of goods from a source location to a destination. These tasks are intrinsically linked to rights and obligations of a tendering party 10, e.g. buyer 12, and an accepting party 20, e.g. seller 22, incorporated in the COS and COP.

[00125] Trade operations management module 3000 may include the trade operations managing method 3010. Trade Operations managing method 3010 may include receiving cargo data from a chartering party 40 via the network, receiving a request signal from the chartering party 40 requesting for at least quotation data and vessel data from at least one shipping party 50 (3024T,3014S), receiving at least the quotation data and vessel data from a shipping party 50 based on the cargo data via the network (3016S,3016T), receiving an agreement signal from the chartering party 40 indicating an agreement with at least the quotation data and the vessel data (3032T,3032S), generating a recap of the agreed charter party terms and conditions along with taking the vessel on subjects (3042S,3042T), nomination of the vessel to the counter party and terminals by the charter party (3052T,3052A), receiving an acceptance of vessel signal from the counter party and terminals (3054A,3054T), sending the fixing vessel clean signal to the shipping party 50 by the chartering party 40 (3062T,3062S), generating a shipping contract based on at least the recap data (3072S,3072T), receiving an agreement signal from the chartering party 40 indicating an agreement with the shipping contract (3074T,3074S) and generating a Bill of Lading document based on at least the cargo data, vessel data, recap data and shipping contract data (3112S). Shipping party 50 may include a shipping company. [00126] Trade operations management module 3000 begins when a chartering party 40 starts to look for a vessel for transporting cargo or goods to be shipped from the accepting party 20 and tendering part 10. Chartering party 40 may include the tendering party 10 or the accepting party 20. Chartering party 40 may include one of the tendering party 10 and the accepting party 20 such that a counter party 60 includes the other of the tendering party 10 or accepting party 20. In other words, where one party, e.g. tendering party 10, may be the chartering party 40, the other party, e.g. accepting party 20, may be the counter party 60 and vice versa.

[00127] Chartering party 40 may post cargo data to the trading system 100 such that trade operations management module 3000 receives cargo data from the chartering party. Cargo data may include weight, volume of the cargo, load port, discharge port, preferred loading laycan, major approvals required, etc.

[00128] Referring to Fig. 7, chartering party 40 may post vessel requirements, e.g. vessel data, and request for quotation data on to the trading system 100 (3024T,3014S). Chartering party 40 may check availability of vessel from the trading system 100 (3012T). Chartering party 40 may post the cargo data to the specific shipping company when a suitable vessel is found. On finding a suitable vessel, chartering party 40 may request for a freight quotation from the shipping party 50 (3024T,3014S) after posting relevant cargo data to the shipping party 50. Shipping party 50 may view the cargo data and prepare a quotation and forward the vessel data and quotation data to the chartering party 40 (3016S,3016T). Shipping party 50 may derive the vessel data from the database and quotation data from the cargo data to prepare the quotation. Vessel data may include details of the vessel. Quotation data may be freight and other hiring terms for hiring the vessel. If the chartering party 40 finds the quotation from the shipping party 50 to be acceptable and reasonable, the chartering party 40 may send an agreement signal to the trading system 100, e.g. by clicking an accept button on the computer terminal of the chartering party 40. Once the chartering party 40 confirms the quotation to the shipping party 50 and requests the vessel to be put on subjects, the shipping party 50 may generate a recap of the charter party terms and conditions based on the agreed quotation data and forward the recap to the chartering party 40 via the trading system 100. While doing this, the shipping party 50 gives the chartering party 40 a specific amount of time within which the chartering party 40 has to get the vessel nominated to the counter party 60 and relevant terminals and get the vessel vetted and accepted by them. The chartering party 40 immediately nominates the vessel data along with a "Questionnaire 88", loading laycan, laytime, demurrage, vessel rotation, last three cargoes if required, major approvals available, etc and seeks the vetting and acceptance of the vessel from the counter party 60 and relevant terminals. Once the acceptance is received from the counter party 60 and relevant terminals, the chartering party 40 sends the formal vessel acceptance signal to the shipping party 50 asking them to fix the vessel clean. At this point, the recap between the shipping party 50 and the chartering party 40 becomes a legally binding contract. Once the shipping party 50 receives the signal to fix the vessel clean, the shipping party 50 may generate the shipping contract using the trading system 100 using at least the data from the recap. The chartering party 40 may receive and review the shipping contract and if the chartering party 40 agrees with the shipping contract, the chartering party 40 may send an agreement signal, e.g. digitally sign and stamp the shipping contract, and forward the shipping contract to the shipping party 50 online. Once the cargo is loaded onto the vessel, the shipping party 50 may use the trading system 100 to generate a Bill of Lading (BL) document based on the shipping contract data (3112S). Shipping party 50 may include a company that owns vessels and provides the vessels for transportation of cargoes.

[00129] Trade operations managing method 3010 may include receiving at least cargo data from at least one chartering party. Chartering party 40, i.e. tendering party 10 or accepting party 20, may post cargo data, e.g. their available cargo, on the trading system 100 for shipping parties 50 to view (3022T,3022S). The cargo data may also be viewed by ship brokers 70. Both tendering party 10 and accepting party 20 may post cargo data on the trading system 100. Tendering party 10 and accepting party 20 may be able to post their cargoes or cargo data available with them with a view to getting quotes or quotation data for freights from interested shipping parties 50. The cargo data may be viewed by the shipping parties 50 and ship brokers 70.

[00130] Operations managing method 3010 may include receiving at least vessel data from at least one shipping party 50, said vessel data is visible to the chartering party 40. Shipping party or parties 50 may post vessel data of their vessels that are available to the market via the trading system 100 (3012S). Shipping party 50 may create and post the availability of their vessels to the open market or to middle parties, e.g. ship brokers 70. The vessel data may be accessible or seen by chartering parties 40 so that the chartering party 40 may be able to view the available vessels on the trading system 100. [00131] Trade operations managing method 3010 may include a search query for the chartering party 40 to search for a shipping party 50 that ships a specific class of cargo including Bulk liquid, Dry bulk and Containers. Chartering party 40, i.e. tendering party 10 or accepting party 20, may search for available vessels, a shipping party 50, and/or a ship broker 70. Chartering party 40 and counter party 60 may search for available vessels and view the vessel postings of shipping parties 50. If the chartering party 40 and/or counter party 60 find a suitable vessel, they can request a firm quote or quotation data from the shipping party 50. Chartering party 40 and counter party 60 may search for shipping parties 50 or ship brokers 70. Chartering party 40 and counter party 60 may narrow down their search by retrieving only those shipping parties 50 who ship a specific class of cargo, e.g. Bulk liquid, Dry bulk or Containers.

[00132] Trading system 100 may provide a match making feature such that trading system may automatically match the cargo available with the vessels available thereby providing the advantage of making the process of choosing cargoes/vessels for parties easier.

[00133] Operations managing method 3010 may include generating a recap document based on at least the cargo data, quotation data, shipping data and vessel data upon receiving the agreement signal from both chartering party 40 and shipping party 50 upon mutual agreement. Trade operations managing method 3010 may further include forwarding the recap document to the chartering party 40 by the shipping party 50 (3042S,3042T). Chartering party 40 may receive the recap generated by the shipping party 50. A recap may be a document capturing all the details or data pertaining to the shipment. The shipping transaction may also start with the recap if the parties so desire, skipping the initial steps of finding and negotiating the vessel on the trading system 100. Shipping party 50 and chartering party 40 may modify the recap via the trading system 100 if the recap generated does not accurately reflect the details of the deal until a confirmation is made (3044T,3044S).

[00134] Trade operations managing method 3010 may include a feature of vessel nomination whereby the chartering party 40 forwards the vessel data to a counter party 60 after receiving the recap from the shipping party 50. Once the recap is received, the chartering party 40 may nominate the vessel to the counter party 60 by forwarding the vessel data including "Questionnaire 88", loading laycan, laytime, demurrage, vessel rotation, last three cargoes if required, major approvals available, etc to the counter party 60 (3052T,3052A). Chartering party 40 may nominate a vessel to their counter party 60 and other related terminals seeking the vetting and acceptance of the vessel. Vessel nominations may be countered, rejected or confirmed by the counter party 60 (3054A,3054T). Once the vessel is accepted by the chartering party 40 and relevant terminals, the chartering party 40 may send the formal vessel acceptance signal to the shipping party 50 (3062T,3062S).

[00135] Trade operations managing method 3010 may include receiving a confirmation signal from the chartering party 40 and countering party 60 confirming the vessel nomination. The chartering party 40 and the counter party 60 may confirm the vessel to be hired and then the chartering party 40 may forward their confirmation to the shipping party 50 (3062T,3062S) upon which the recap becomes a legally binding contract between the shipping party 50 and chartering party 40.

[00136] Trade operations managing method 3010 may include a provision for the counter party 60 and terminals to modify a few "non deal-breaker" parameters of the recap namely laycan, laytime, demurrage rate, etc before sending the vessel confirmation signal. After nominating the vessel to the countering party 60, the chartering party 40 and/or the counter party 60 may modify and counter the vessel nomination before arriving at an acceptance of the vessel data by the countering party 60 and hence the vessel (3054T,3054A). Once all aspects of the vessel nomination are agreed between the chartering party 40 and countering party 60, the countering party 60 may send a formal vessel acceptance signal to the chartering party 40 (3054A,3054T) who in turn sends the vessel confirmation signal to the shipping party 50 (3062T,3062S). At this point, the vessel gets fixed clean and the recap becomes a legally binding contract.

[00137] Upon fixing the vessel clean, the shipping party 50 may generate the shipping contract automatically, digitally sign and stamp exchange the shipping contract with the chartering party 40 who may in turn digitally sign and stamp the shipping contract.

[00138] Trade operations managing method 3010 may include generating a shipping contract by the shipping party 50 upon receiving the agreement signal from the chartering party 40. Once the charterer confirms the vessel to the shipping party 50, the shipping party 50 may generate the shipping contract (3072S,3072T). The chartering party 40 may view the shipping contract generated by the shipping party 50. Shipping party 50 may generate the shipping contract using predefined formats. [00139] Trade operations managing method 3010 may include digitally signing and stamping the shipping contract by the shipping party 50 and forwarding the signed shipping contract to the chartering party 40 over the computer network. After generating the shipping contract, the shipping party 50 may endorse on the shipping contract by digitally signing and stamping the shipping contract and thereafter transmit the shipping contract to the chartering party 40 (3082S,3082T).

[00140] Trade operations managing method 3010 may include digitally signing and stamping the shipping contract by the chartering party 40 and forwarding the signed shipping contract to the shipping party 50. After receiving the shipping contract from the shipping party 50, chartering party 40 may endorse the shipping contract and digitally sign and stamp the shipping contract and exchange it with the shipping party 50 online (3084S,3084T). Chartering party 40 and shipping party 50 may edit and modify the shipping contract before finally confirming the contents of the shipping contract (3074T,3074S).

[00141] Chartering party 40 and counter party 60 may nominate a surveyor 52. Surveyor 52 inspects the quality, quantity, vessel cleanliness and other parameters of the cargo and the vessel. Survey instructions may be generated by the chartering party 40 and/or counter party 60 and sent to the surveyor 52 via the trading system 100 (3092T,3092SR). Operations managing method 3010 may include generating and sending survey instructions to the surveyor 52. Operations managing method 3010 may include generating at least one certificate by the surveyor 52 from the trading system 100. Operations managing method 3010 may include forwarding the at least one certificate to the chartering party 40 or the countering party 60 as the case may be. The certificates may include at least Certificate of Quantity, Certificate of Quality, Vessel Tank Inspection report, etc. Surveyor 52 may generate the necessary certificates from the system for a particular transaction. All the necessary information about a particular transaction may be easily available to the surveyor 52. The trading system 100 may automatically pick up the necessary values for a particular transaction at the time of generating the certificates. The certificates may then be sent to the chartering party 40 and/or counter party 60 as the case may be i.e. tendering party 10 (3102T), accepting party 20 (3102 A) and shipping party 50 (3102S). Chartering party 40 and counter party 60 may view the contact details of surveyors 52 available on the trading system 100. Chartering party 40 and counter party 60 may view the draft of the certificates generated by the surveyor 52. Chartering party 40 and/or countering party 60 may edit and modify the documents (portions which they are authorized to modify) before confirming them. Upon confirming, chartering party 40 and counter party 60 may receive the original documents from the surveyor 52. The certificates may be digitally signed and stamped by the surveyor 52 . Both chartering party 40 and counter party 60 may receive a copy of the certificates ensuring automatic verification of authenticity when either party receive the certificates from the other party.

[00142] Once the cargo is loaded onto the vessel, the shipping party 50 may use the trading system 100 to generate a full set of Bill of Lading (BL) document based on the details of the ship contract, vessel data and cargo data (3112S). . The BL may be digitally signed and stamped by the shipping party 50. The BL can then be sent to the shipper who is the owner of the cargo and may or may not be the chartering party 40. Once the vessel leaves the port, the shipping party 50 may send updates of the vessel to the chartering party 40. Shipping party 50 may also request for Letter of Indemnity (LOI) from the chartering party 40 (3242S,3242T) for cargo release without presenting the original BL by the receiver at the port of discharge, issue Cargo release order (3144S,3142T), raise demurrage claim and generate the freight invoice using the trading system 100. Chartering party 40, e.g. buyers 12, and counter party 60, e.g. sellers 20, may have the functionality of generating and exchanging the LOI.

[00143] In the trade operations management module 3000, chartering party 40 and counter party 60 may receive vessel updates generated by the shipping party 50 from the trading system 100.

[00144] Shipping parties 50 may generate freight invoice and send it to the chartering party 40. Chartering party 40 may send Payment Instruction to a bank, e.g. opening bank 14.

[00145] Chartering party 40 may send BL instructions to the shipping party 50. Chartering party 40 may receive a Draft BL generated by the shipping party 50. The draft BL may either be confirmed or modified (portions which they are authorized to modify) by the chartering party 40. Upon confirming the draft BL, the shipping party 50 may generate the complete set of original BL's through the system. The shipping party 50 may then digitally sign and stamp the BL's and forward the complete set of BL's to the shipper who may be the chartering party 40 or the seller of the goods to the chartering party 40. [00146] Referring to Fig. 8, trade operations management module 3000 may include the option of allowing the chartering party 40 and/or counter party 60 to receive an LOI request from the shipping party 50 (3242S,3242T). Chartering party 40 and counter party 60 may generate the LOI by retrieving relevant details for a particular transaction from the trading system 100. Shipping party 50 may raise LOI request via the trading system 100 and send the LOI request to the chartering party 40.

[00147] A draft LOI may be generated and modified by and between the chartering party 40 (3244T), the counter party 60 (3244A) and the shipping party 50 (3244S) until an agreement is reached on the LOI format and contents. Once agreed and confirmed, an original LOI may be generated by the countering party 60 (3246A) and/or chartering party 40 (3246T) and sent to the shipping party 50 (3246S) by the chartering party 40 for review, approval and acceptance. Upon the shipping party 50 receiving an acceptable LOI, the shipping party 50 may release the Cargo release order to the receiver at the discharge port who maybe the countering party 60 or their nominee. A copy of the Cargo release order is also sent to the shipping party agents at the port of discharge by the shipping party 50.

[00148] Trade operations management module 3000 may include the option of allowing the shipping party 50 to raise demurrage claim and send the demurrage claim to the chartering party 40. Chartering party 40 may receive demurrage claims from the shipping party 50. In turn, chartering party 40 may raise the demurrage claim to the counter party 60.

[00149] Trade operations management module 3000 may include the option of allowing tendering party 10 or accepting party 20 (whoever is the chartering party 40 of the vessel) to receive the freight invoice from the shipping party 50.

[00150] Trade operations management module 3000 may include the option of allowing shipping party 50 to send vessel updates to the chartering party 40 and the counter party 60.

[00151] Trade operations management module 3000 may include the option of allowing a cargo release order to be issued by the shipping party 50 via the trading system 100 (2248S,3248T).

[00152] Trade operations management module 3000 may include the option of allowing shipping party 50 through a captain of the ship to issue the notice of readiness (NOR) to the receiving terminal and the receiver who maybe the countering party 60 or their nominee using the trading system 100.

[00153] Trade operations management module 3000 may include the option of allowing ship brokers to use all the functionalities of the shipping parties 50 with an exception that they cannot digitally sign and stamp the ship contract and the Bill of Lading (BL). Ship brokers may be provided with the functionality of getting the documents signed and stamped from the shipping party 50 before sending it to the chartering party 40.

[00154] Referring to Fig. 8, trade operations management module 3000 may allow a chamber of commerce 72 to receive a copy of the invoice and the BL from the counter party 60, e.g. seller 22 (3122A,3122C). The chamber of commerce 72 may also receive a copy of the BL directly from the shipping party 50 ensuring automatic verification of authenticity of the BL when the chamber of commerce 72 receives the same from the countering party 60. The chamber of commerce 72 may generate and digitally sign and stamp the certificate of origin (COO) and send the COO to the counter party 60 (3132C,3132 A).

[00155] All the trade documents required by all the parties to complete the trade transaction may be generated and exchanged online and may be immediately visible to the authorized parties. All the activities related to a particular transaction may be tracked by the trading system 100 and thereby the trading system 100 attempts to prevent users from making mistakes and prevents any possibility of fraud. Since all the documents are created by authorized users on the platform, there is minimal probability of fraud.

[00156] Trading system 100 may make all the documents available immediately to the authorized users. Hence, the BL may be immediately available to the chartering party 40, e.g. seller 14 and therefore to the tendering party 10 e.g. buyer 12 thereby eliminating the need for LOI.

[00157] The original BL may be made available to the authorized party and once the original BL is printed and/or retrieved from the trading system 100 by the authorized party, the original BL may be automatically deleted from the trading system 100 thereby making sure that multiple sets of title documents are not prepared and are not available for the same transaction. [00158] Fig. 7A shows a varied flow diagram of the flow diagram in Fig. 7 wherein trade operations management module 3000 may include a ship broker 70 for brokering a shipping deal between shipping company and the chartering party 40. The key events in the flow diagram in Fig. 7 are similarly found in the flow diagram in Fig. 7 A.

[00159] Trade Document Management Module

[00160] Trading system 100 may include a trade document management module 4000 (refer to Fig. 1). Trade document management module 4000 may include a document database 4502 (refer to Fig. 9A) that contains all the documents generated for a given transaction. Documents may be automatically generated by picking up relevant values for a particular transaction. For example, while generating the COS and/or COP, all the relevant deal conditions will be automatically populated from the deal confirmation. The trading system 100 may provide parties with multiple formats to generate a document. Parties may select an available format or choose to create a new format. Previously generated documents may be retrieved and changes may be made to create a new document making the task of generating new documents easier.

[00161] Authorized parties may digitally sign and stamp the documents they generate. If a user does not have the privilege of signing and stamping a document, he can raise an alert to the concerned person who has the privilege of signing and stamping the document. Original and copies may be distinguished on the trading system 100 using watermarks. Trading system 100 may permit parties to forward and print copies of documents.

[00162] Using the trading system 100, accepting party 20 may collect all the documents as per LC requirements or documentary instructions and send the originals and copies of these documents to their bank or to the countering party 60 as the case may be. Accepting party 20, e.g. seller 22, may request the advising bank 24 to check the documents if required. If the accepting party 20 does not require the documents to be checked, the advising bank 24 may directly send all the documents to the opening bank 14. If the advising bank 24 happens to check the documents and find discrepancies, they may send a list of the discrepancies to the accepting party 20. Accepting party 20 may now decide the course of action for the advising bank 24. Accepting party 20 may ask the advising bank 24 to send the documents as it is to the opening bank 14 without mentioning the discrepancies, to hold the documents until further instructions or to send the documents with the discrepancies to the opening bank 14.

[00163] Once the opening bank 14 receives all the documents, the opening bank 14 may check the documents for discrepancies. If discrepancies are found, the opening bank 14 may send a list of discrepancies together with a copy of the documents like BL, invoice, etc to the tendering party 10. If no discrepancies are found, then the opening bank 14 may send a copy of all the documents to the tendering party 10, e.g. buyer 12. On receiving the documents with or without discrepancies, the tendering party 10 may review the documents. Tendering party 10 has the option to reject or accept the documents if those documents have been presented with discrepancies. If the tendering party 10 rejects the documents, the accepting party 20 may recall the original documents. In such a scenario, the opening bank 14 sends all the original documents back to the advising bank 24 which in turn sends them back to the accepting party 20.

[00164] Tendering party 10 and accepting party 20 may also generate the shipment advice and send documents to internal security and customs. Each party can also view all the documents relevant to the party for any given transaction on a single window as soon as the documents are generated and the party generating such documents authorizes them access to those documents.

[00165] Trade document management module 4000 enables each party to send documents to the concerned counterparty. Documents may seamlessly flow from one party to another thereby ensuring that authorization is maintained during the flow. In addition, accepting party 20 is able to use the trading system 100 to collate or gather all the documents as per LC conditions or documentary instructions. Trading system 100, via the trade document management module 4000, ensures that all the requirements as per LC or the documentary instructions of the tendering party 10 are met and thereby reducing the possibility of errors. Each party may also view all the documents relevant to the party for any given transaction on a single window as soon as the documents are generated and as soon as the party generating such documents authorizes them access to those documents.

[00166] Comparing with current practices wherein it takes many days from the time a document is created for it to be seen by others, in the trading system 100 the documents may be visible almost immediately to the receiver when they are transmitted on via the trading system 100. Only authorized parties are able to access the documents. Trading system 100 allows authorized parties to digitally sign and stamp the documents.

[00167] Original documents and copies of originals may be distinguished using watermarks. All transmission is done on a secured channel thereby eliminating the risk of fraud using forged documents.

[00168] Referring to Fig. 9, tendering party 10 and accepting party 20 may have the option of sending statutory documents to the customs 82 (refer to Fig. 9A) and government agencies 84 (4012T,4012C). The customs 82 and government agencies 84 may interact with the tendering party 10 and accepting party 20 and request for documents using the trade document management module 4000. Insurance company 74 may forward the insurance certificate to the trade document management module 4000, into the document database 4502. Tendering party 10 and accepting party 20 may request for and send relevant documents to and from the trade document management module 4000 (4022A,4022G).

[00169] Fig. 9 A shows a flow diagram of the relevant documents which are transmitted between the parties as mentioned above. Documents sent by the various parties may be saved into the document database 4502. At the same time, documents may be retrieved from the document database 4502 for forwarding to the relevant parties. Access to the document database 4502 may be authenticated by an authentication system to ensure that only documents from authorised parties are allowed to be saved in the document database 4502 and only authorized parties are able to retrieve the documents from the database.

[00170] Resource Management Module

[00171] Trading system 100 may include a resource management module 5000. As shown in Fig. 10, resource management module may include a Position List 5010 such that the Position List 5010 is able to give out the short/long position for an organization at a given point in time by product and/or by trader and/or by region/office. Resource management module 5000 allows a senior functionary or executive of an organization (tendering party 10 or accepting party 20) to monitor live the performance of their trading employees on a real time basis in order to take any corrective action if necessary.

[00172] Resource management module 5000 may automatically match the position for an organization on the sell and buy side for a given product based on a built in algorithm. A party then has the option to modify the matched pairing if the party is of the opinion that it is necessary.

[00173] Resource management module 5000 may include generating a marked to market (MTM) report 5020, wherein resource management module 5000 provides the management of an organization (e.g. tendering party 10 or accepting party 20) a snapshot information or status update of the current exposure on their books in terms of product- wise, trader-wise, region/office- ise. MTM report will accurately reflect an organizations (tendering party 10 or accepting party 20) market exposure in dollar terms and may further have charting tools to hone in on a hedging strategy to effectively counter the risks. It also helps on organization to keep refining the risk management strategies to hedge any perceived risks due to the long short position.

[00174] Resource management module 5000 may include risk management tools 5030 and market analysis tools to allow effective steps to be taken to counter the risk on the book. Risk management tools 5030 and market analysis tools may include fundamental and technical analysis tools for a given product.

[00175] Resource management module 5000 may include generating a Deals and Prices report 5040 wherein the Deals and Prices report 5040 provides a party historical prices for a given product in different geographical regions. The Deals and Prices report 5040 also provides access to parties on information regarding deals concluded for a given product.

[00176] Resource management module 5000 may raise alerts 5050, e.g. operational alerts, at every important stage of the supply chain process, for example, raising an alert to prepare draft COS/COP if it has not been done within the pre-specified time frame after the generation of the deal confirmation. These alerts 5050 may be generated by the resource management module 5000 automatically once the party has set a pre-defined criterion for receiving these alerts 5050. The alerts may be sent to the parties via email and/or to their listed mobile phone. Alerts 5050 may include payment alerts to remind parties of payments to be made or to be received.

[00177] Resource management module 5000 may provide parties an auction tender sub-module to conduct auctions/float tenders online to pre-approved counterparties to achieve the best possible outcome for either placing the product or sourcing their raw material. Once the deals are concluded using sub-module the rest of the supply chain tasks can be performed using the trading system 100 as mentioned.

[00178] Fig. 11 shows the interaction of the trading system 100 with external systems and users/customers 112. Trading system 100 may be designed to serve registered and authorized users who either access the platform through internet or via Restful clients 114 which are clients who try to communicate with the trading system 100 using a web interface (using a standalone application). Trading system 100 provides secured access to parties by transmitting client's sensitive/confidential data on the computer network in an encrypted form. The access to trading system 100 may be guarded by a firewall. The client data transmission is secured by a standard mechanism used by many organisations, e.g. using DMZ (De-militarized zone or perimeter networking) and SSL (Secure Sockets Layer). SSL is the standard security technology for establishing an encrypted link between a web server and a browser. This link ensures that all data passed between the web server and browsers remain private and integral.

[00179] As mentioned, trading system 100 includes the trade and contract management module 1000 and may include trade finance management module, trade operations management module, trade document management module and resource management module.

[00180] In addition, trading system 100 may include an authentication system 122 which uses a Username-Password combination to authenticate users. The authentication system allows users to perform only those tasks which the user is authorized to. Trading system 100 may include a Transaction system 124. Once a user begins a transaction, the Transaction system 124 would take control. Transaction system 124 is designed to monitor each transaction and assist users in conducting a transaction from start to end of the process. Trading system 100 may include a security system (not shown in Fig. 11). Security system is designed to protect malicious attack and such that users will not have access to any content within the trading system 100 without being authenticated. Authenticated users will have access only to the content of transactions that they are a part of and therefore authorized to access. Authentication system 122 is designed to provide a high level of security to users and their data. Multiple layers of security and encryption techniques are used to authenticate users and allow them to carry out only those tasks that they are authorized to perform. [00181] The transaction system 124 may be connected to a file system 132, a Relational Database Management System (RDBMS) 134 and a Data Warehouse (DWH) 136. File system 132 handles all the documents generated by users and stores them securely. RDBMS 134 is a database that contains all user and transaction related details. DWH 136 is used for data mining and MIS purposes.

[00182] Trading system 100 may include an alert system 142 designed to notify users of their outstanding operational and payment tasks, e.g. when triggered by resource management module 5000. Alert system 142 may have a SMTP (Simple Mail Transfer Protocol) 148 to send reminders to users via email 144 and mobile 146. Alert system 142 on the platform reminds the users on outstanding tasks via Email and Mobile thus ensuring that users can do business on the move.

[00183] To integrate the trading system 100 with other external ERP systems adopted/used by parties of the trading system 100, trading system 100 may include specially designed client adaptors 154. Client adaptors 154 serve as a communication channel between the trading system 100 and the external ERP system. Trading system 100 further provides services to exchange the data for approved client. Trading system 100 uses Client adaptors to integrate with the users ERP systems thus eliminating the need for redundant data entry.

[00184] In addition, trading system 100 may include a process queue 152 for asynchronous alert notification, a batch processor 156 for scheduling alerts, archiving data and preparing reports, and an MIS 158 for retrieving various data for preparation of reports.

[00185] As a skilled person would have appreciated, trading system 100 brings together the modules of the entire supply chain onto a single platform. All the parties involved in the supply chain including government agencies are connected on the platform making the process more efficient and reducing the possibility of errors and fraud. Trading system 100 offers a mechanism of paperless trade thereby making the process simpler, easier, faster, highly efficient and safe.

Claims

1. A method comprising, receiving tender data f om a tendering party via a computer network; storing the tender data in a database; receiving a confirmation signal from an accepting party indicating an acceptance of a deal between the tendering party and the accepting party based on the tender data; retrieving the tender data of the confirmed deal from the database; generating a first draft contract for the tendering party based on at least the tender data of the confirmed deal; and generating a second draft contract for the accepting party based on at least the tender data of the confirmed deal.

2. The method of claim 1, further comprising, receiving an agreement signal from the tendering party indicating a finalization of the first draft contract; receiving an agreement signal from the accepting party indicating a finalization of the second draft contract; forwarding a finalized first contract digitally to the accepting party; forwarding a finalized second contract digitally to the tendering party; receiving an endorsement signal from the accepting party indicating an endorsement of the finalized first contract; receiving an endorsement signal from the tendering party indicating an endorsement of the finalized second contract; forwarding the endorsed first contract via the computer network to the tendering party; and forwarding the endorsed second contract via the computer network to the accepting party.

3. The method of claim 1 or 2, wherein the tender data comprises new data generated by the tendering party or accepting party or data modified from previous tenders.

4. The method of any one of claims 1 to 3, further comprising modifying the tender data by at least one of the tendering party or accepting party after receiving the tender data and before receiving the confirmation signal.

5. The method of claim 4, wherein the modification of the tender data by at least one of the two parties is tracked and highlighted to the other party.

6. The method of any one of claims 1 to 5, further comprising generating a deal confirmation upon receiving the confirmation signal and forwarding the deal confirmation to the tendering party and the accepting party.

7. The method of any one of claims 1 to 6, wherein at least one of the first or second draft contract is generated based on one or more predefined format or a new user defined format.

8. The method of any one of claims 1 to 7, further comprising receiving modification of at least one of the first draft contract or the second draft contract before forwarding the finalized first and second contracts to the tendering party and accepting party respectively.

9. The method of claim 8, wherein the modification of the first draft contract or second draft contract by the respective parties is tracked and highlighted to the other party.

10. The method of any one of claims 1 to 9, further comprising digitally signing and stamping the finalized first contract by the tendering party before forwarding the finalized first contract to the accepting party.

11. The method of any one of claims 1 to 10, further comprising digitally signing and stamping the finalized second contract by the accepting party before forwarding the finalized second contract to the tendering party.

12. The method of any one of claims 1 to 1 1, wherein the tendering party includes a buyer and the accepting party includes a seller.

13. The method of claim 12, further comprising, generating a Letter of Credit format by the accepting party; forwarding the Letter of Credit format to the tendering party by the accepting party; generating a Letter of Credit application by the tendering party based on data from at least one of the following: the first contract, second contract and or Letter of Credit format.

14. The method of claim 13, further comprising, forwarding the Letter of Credit application to the accepting party; receiving an endorsement signal indicating an acceptance of the Letter of Credit application from the accepting party; and forwarding the Letter of Credit Application to various banks generating a Letter of Credit based on the endorsed Letter of Credit application.

15. The method of claim 13 or 14, further comprising modifying the Letter of Credit application by at least one of the tendering party or the accepting party after forwarding the Letter of Credit application to the accepting party.

16. The method of any one of claims 13 to 15, wherein the endorsed Letter of Credit application is forwarded to an opening bank engaged by the tendering party, wherein the original Letter of Credit is generated by the opening bank based on the Letter of Credit - application, the method further comprising modifying of the endorsed Letter of Credit application by at least one of the tendering party or the opening bank prior to generating the Letter of Credit.

17. The method of claim 16, wherein the modified endorsed Letter of Credit application is forwarded to the accepting party for consent prior to generating the Letter of Credit.

18. The method of any one of claims 13 to 17, further comprising generating a draft Letter of Credit based on the endorsed Letter of Credit application and forwarding the draft Letter of Credit to the tendering party prior to generating the Letter of Credit.

19. The method of claim 18, wherein the draft Letter of Credit is forwarded to the accepting party by the tendering party.

20. The method of claim 18 or 19, further comprising modifying the draft Letter of Credit by at least one of the tendering party or the accepting party.

21. The method of any one of claims 18 to 20, further comprising receiving an approval signal from the tendering party and generating the Letter of Credit based on the approved draft Letter of Credit.

22. The method of any one of claims 13 to 21 , wherein the Letter of Credit is generated by an opening bank representing the tendering party.

23. The method of claim 22, wherein the Letter of Credit is forwarded by the opening bank to an advising bank representing the accepting party.

24. The method of claim 23, wherein the Letter of Credit is forwarded by the advising bank to the accepting party.

25. The method of any one of claims 1 to 24, further comprising, receiving cargo data from a chartering party via the network; receiving a request signal from the chartering party requesting for at least quotation data and vessel data from at least one shipping party; receiving at least the quotation data and vessel data from a shipping party based on the cargo data via the network; receiving an agreement signal from the chartering party indicating an agreement with at least the quotation data and the vessel data; generating a shipping contract based on at least the quotation data; receiving an agreement signal from the chartering party indicating an agreement with the shipping contract; and generating a Bill of Lading document based on at least the cargo data, vessel data and shipping contract data.

26. The method of claim 25, further comprising receiving at least cargo data from at least one chartering party.

27. The method of claim 25 or 26, further comprising receiving at least vessel data from at least one shipping party, said vessel data visible to the chartering party.

28. The method of any one of claims 25 to 27, further comprising receiving a search query from the chartering party to search for a shipping party.

29. The method of any one of claims 25 to 28, further comprising generating a recap document based on at least the cargo data, quotation data, shipping data and vessel data upon receiving the agreement signal.

30. The method of claim 29, further comprising forwarding the recap document to the chartering party.

31. The method of any one of claims 25 to 30, further comprising forwarding the vessel data to a counter party after receiving the agreement signal from the chartering party in the form of a vessel nomination.

32. The method of claim 31 , further comprising receiving a confirmation signal from the chartering party and countering party confirming the vessel data.

33. The method of claim 32, further comprising modifying the vessel data before receiving the confirmation signal.

34. The method of any one of claims 25 to 33, further comprising generating a shipping contract by the shipping party upon receiving the agreement signal from the chartering party.

35. The method of claim 34, further comprising digitally signing and stamping the shipping contract by the shipping party and forwarding the signed and stamped shipping contract to the chartering party over the computer network.

36. The method of claim 35, further comprising digitally signing the shipping contract by the chartering party and forwarding the signed shipping contract to the shipping party.

37. The method of any one of claims 25 to 36, wherein the chartering party includes one of the tendering party and the accepting party; and wherein the counter party includes the other of the tendering party and accepting party.

38. The method of any one of claims 25 to 37, further comprising receiving a request from a tendering/accepting party for at least one certificate and generating at least one certificate by the surveyor.

39. A system comprising, a receiving module configured to receive tender data from a tendering party via a computer network; a database configured to store the tender data; the receiving module configured to receive a confirmation signal from an o

accepting party indicating an acceptance of a deal between the tendering party and the accepting party based on the tender data; a retrieving module configured to retrieve the tender data of the confirmed deal from the database; and a generating module configured to generate a first draft contract for the tendering party based on at least the tender data of the confirmed deal and a second draft contract for the accepting party based on at least the tender data of the confirmed deal.

40. The system as claimed in claim 38, further comprising, a forwarding module configured to forward a finalized first contract digitally to the accepting party; the forwarding module configured to forward a finalized second contract digitally to the tendering party; wherein the receiving module is configured to receive an agreement signal from the tendering party indicating the finalization of the first draft contract; wherein the receiving module is configured to receive an agreement signal from the accepting party indicating the finalization of the second draft contract; wherein the receiving module is configured to receive an endorsement signal from the accepting party indicating the endorsement of the first contract; wherein the receiving module is configured to receive an endorsement signal from the tendering party indicating the endorsement the second contract; wherein the forwarding module is configured to forward the endorsed first contract via the computer network to the tendering party; and wherein the forwarding module is configured to forward the endorsed second contract via the computer network to the accepting party.