专利汇可以提供ENERGY COLLABORATION PLATFORM专利检索,专利查询,专利分析的服务。并且Methods and systems for managing the settlement processes for bilateral traded energy products in the wholesale energy industry including transaction selection, collaborative tie-out, invoicing, payment execution, dispute management, and credit management processes. One embodiment provides collaborative, on-line environments for performing tie-out activities, managing transaction disputes, processing invoices, making payments, managing credit exposure, and interactively communicating actions and comments. Embodiments can also provide automatic notification and alert sequences during the tie-out process, the invoicing process, the payment process, the disputed transaction process, and the credit management processor. The notifications and alerts can be provided publicly among counterparties as well as privately among users within a counterparty's organization. Another embodiment of the invention manages a configurable workflow sequence to fully automate review and approval of eligible matched transactions from tie-out through invoicing and payment between counterparties while simultaneously requiring users to take actions to manually process remaining out-trade transactions.,下面是ENERGY COLLABORATION PLATFORM专利的具体信息内容。
What is claimed is:
This application claims priority to U.S. Provisional Patent Application No. 61/835,228 filed Jun. 14, 2013, the entire content of which is hereby incorporated by reference.
Embodiments of the present invention relate to methods and systems for managing and settling wholesale energy trading transactions between counterparties.
Energy companies trade wholesale energy transactions with bilateral counterparties for various energy commodity products, including but not limited to electricity, electricity capacity, electricity ancillary services, electricity transmission (which trades in various combinations as “power”), coal, renewable energy, renewable energy credits, crude oil, distillate fuels, natural gas, and financial swaps and options linked to energy commodity products.
Wholesale energy transactions are currently invoiced on a 30-day cycle, with the operational and financial accounting activities beginning on the first day of the month following the transaction delivery. Invoices are typically distributed on the 10th business day of the month following the transaction delivery month, with payments due on the 20th business day of the month (10 days after the receipt of the invoice). The existing invoice cycle is labor-intensive and inefficient, forcing trading organizations to hold high levels of unsecured credit exposure and/or post significant amounts of collateral or provide balance sheet commitments to support their energy trading activity.
During the transaction delivery month, transactions details, such as quantity, price, delivery point, date, e-Tag, and time, are entered into a transaction system of record (such as an Energy Trading Risk Management (“ETRM”) system). During the first few days of the month following the delivery month, the invoicing process for the previous month's transactions begins. Transaction counterparties conduct a process known as tie-out with each counterparty to whom they delivered or traded an energy product during the previous month. The purpose of the tie-out process is to ensure that counterparties agree to the transaction details (date, term, volume and price) prior to the invoice being generated and distributed. During the tie-out process, the counterparties manually review (e.g., via phone, fax, or email) the transaction volume and price for each transaction that is to be included on the monthly invoice. The manual tie-out effort is a very time-consuming, tedious and subject to a high degree of error due to the requirement that both counterparties exactly match the information provided by the other counterparty to approve the invoiced transactions. Each transaction delivered during the previous month must be tied out or matched and approved by the bilateral counterparty for inclusion on the monthly invoice.
Transactions without any discrepancies (i.e., “matched”) are ready to be invoiced. If there are any transactions with a discrepancy (i.e., “out-trades”), the counterparties attempt to resolve the out-trade prior to issuing the invoice, potentially delaying the distribution of the invoice for those transactions for which there were no discrepancies (i.e., matched transactions). To resolve the out-trades, the bilateral counterparties download transaction data from one or more internal proprietary systems in a format that can be shared with the transaction's bilateral counterparty (e.g., spreadsheets sent via fax, emails, or other manual off-line systems), which enables bilateral counterparties to view the other counterparty's representation of the transaction details. Settlement analysts from both counterparties then manually identify and reconcile the out-trade discrepancy data for each out-trade transaction (e.g., date, term, volume, price, delivery point, index), manually determine the adjustment(s) to be made by each counterparty, and facilitate adjustments to the transaction system(s) of record (e.g., ETRMs) to correct the discrepancies prior to invoicing the transaction. The manual matching of transactions and the reconciliation of out-trade transactions is a time-consuming and cumbersome process. Resolution of each out-trade may also result in a manual adjustment to a transaction for inclusion on the invoice, the need to make a change to the transaction data in the transaction system of record, or, if both counterparties are unable to agree on the transaction details on a timely basis, a formal dispute being lodged against the bilateral counterparty. Resolution details of an out-trade are sometimes, but not always, noted in the transaction system of record.
The bilateral transaction counterparties also execute master energy purchase and sale agreements that govern the terms and conditions for the transactions, including the invoicing period, the timeliness of payment, the payment options, the responsibility for initiating the generation of invoices, and the process for resolving disputed transactions. Accordingly, each transaction must adhere to the terms and conditions of the master agreements, the terms of which can differ between different trading counterparties.
Following a successful manual tie-out process, the matched transactions are ready to be invoiced. A bilateral counterparty to whom payment is due (i.e., the “payee”) prepares an external invoice and distributes it to the bilateral counterparty from which a payment is due (i.e., the “payor”). The external invoice is then distributed to the payor (e.g., by email, fax, secure FTP site, or other manual off-line systems). The payor also prepares an internal invoice. The internal invoice is not distributed, but is used for control purposes to confirm the amount due on each external invoice received from the payee.
An accounts receivable analyst associated with the payee monitors on-line bank reconciliation reports for both “full” and “partial” payments from the payor. Upon bank payment confirmation of a “full” payment (i.e., 100% of the invoice amount), the accounts receivable analyst changes the invoice status from “issued” to “paid” (e.g., in the payee's ETRM), which completes the invoice cycle for the payee. Upon bank payment confirmation of a “partial” payment (i.e., less than 100% of the invoice amount), the accounts receivable analyst changes the invoice status from “issued” to “partially paid” and confirms that a dispute has been created covering the remaining invoice unpaid balance.
For invoices for which a payment is due, an accounts payable analyst associated with the payor waits to receive an invoice from the payee (e.g., via email, fax, through an FTP site, etc.). Upon receipt of the invoice, the accounts payable analyst manually reviews the received invoice to ensure the internal invoice is consistent with the received invoice. If the invoices are inconsistent, the accounts payable analyst works with the payee to resolve discrepancies, potentially delaying full payment. If the received invoice is consistent with the internal invoice, the accounts payable analyst prepares an invoice packet that includes the received invoice and the internal invoice, banking information, and supporting documentation used to prepare the invoice, including any comments from the tie-out process. The invoice packet is reviewed by the payment party's management and then approved for payment execution. The account payable analyst then executes the bank payment arrangements to pay the payee and changes the invoice status to “paid” (e.g., in the payor's ETRM), which completes the invoice cycle. Payment to a party can be made using bank checks, wire transfers, or ACH. If the received invoice is inconsistent with the internal invoice and resolution of the discrepancy is not possible by the required payment date of the terms of the master energy purchase and sale agreement executed between the counterparties, the accounts payable analyst associated with the payor prepares an invoice packet to pay a “partial payment” and at the same time initiates a dispute with the payee for the difference between the invoice amounts.
Throughout the invoice development and execution process, the financial accounting department for each party pulls information from the operational accounting system of record to determine revenue and power purchase accruals and actuals for the previous month, to manually make appropriate journal entries in the financial accounting system of record, to project cash flows for movement of funds, and to adjust the credit exposure information associated with each counterparty.
Accordingly, embodiments of the invention provide systems and methods for managing the bilateral counterparty (e.g., direct or indirect) wholesale energy transaction settlement process. In particular, the systems and methods provide collaborative, on-line workspaces that manage the workflows and notifications for tie-out, invoicing, payment execution, dispute management, and credit management activities associated with settlement of wholesale energy transactions. As used in the present application, the terms “collaborate” or “collaborative” includes providing a seamless workflow between two or more entities. For example, the workflow allows two or more independent parties to participate in a seamless workflow containing multiple steps, check-points, and confirmations. In particular, parties can access information associated with transactions and make changes and/or comments regarding the information. The workflow also automatically notifies parties of changes and/or comments made by other parties or other tasks required of a party to progress the workflow. In some embodiments, the workflow can also be automated if the parties are willing to turn this feature “on.”
In some embodiments, the systems and methods provide an interactive, on-line tool that automatically matches bilateral counterparty wholesale energy transactions during the tie-out process. Some embodiments also create and pay invoices, which ensures invoices are issued on time and securely facilitates payment of bilateral transactions. Using the previously-mentioned functionality, some embodiments shorten the invoice cycle from monthly to weekly or daily, which reduces counterparty credit exposure and the capital necessary to transact. For example, in some embodiments, the systems and methods provide automatic transaction matching, tie-out, and settlement (e.g., invoicing) at level consistent with a unit of trade associated with the transactions (e.g., hourly).
Embodiments of the invention also provide a collaborative, on-line tool to coordinate between bilateral transaction counterparties to resolve disputed transactions and to reduce bilateral counterparty credit exposure to wholesale energy transaction bilateral counterparties.
For example, one embodiment of the invention provides a method of managing wholesale energy trading transaction between a first party and a second party. The method includes creating a tie-out period, receiving first transaction details from a transaction system of record of the first party, and determining a set of the first transaction details from the first party for inclusion in the tie-out period. The method also includes receiving second transaction details from a transaction system of record of the second party, determining a set of the second transaction details from the second party for inclusion in the tie-out period, automatically, by the server, matching the set of the first transaction details with the set of the second transaction details to identify a matched transaction, and making the matched transaction available for review by the first party and the second party.
Other aspects of the invention will become apparent by consideration of the detailed description and accompanying drawings.
FIGS. 16 and 18-19 are notifications generated by the ECP during the collaborative tie-out process of
Before any embodiments of the invention are explained in detail, it is to be understood that the invention is not limited in its application to the details of construction and the arrangement of components set forth in the following description or illustrated in the accompanying drawings. As described in subsequent paragraphs, the specific configurations illustrated in the drawings are intended to exemplify embodiments of the invention and that other alternative configurations are possible. Accordingly, the invention is capable of other embodiments and of being practiced or of being carried out in various ways.
Also, it is to be understood that the phraseology and terminology used herein is for the purpose of description and should not be regarded as limited. The use of “including,” “comprising” or “having” and variations thereof herein is meant to encompass the items listed thereafter and equivalents thereof as well as additional items. The terms “mounted,” “connected” and “coupled” are used broadly and encompass both direct and indirect mounting, connecting and coupling. Further, “connected” and “coupled” are not restricted to physical or mechanical connections or couplings, and can include electrical connections or couplings, whether direct or indirect. Also, electronic communications and notifications may be performed using any known means including direct connections, wireless connections, etc.
It should also be noted that a plurality of hardware and software based devices, as well as a plurality of different structural components may be utilized to implement the invention.
It should be understood that the application server 2 and the other servers and computing devices described herein include standard components of a computing device. In particular, the application server 2 can include a processing unit (e.g., a microprocessor), one or more non-transitory computer-readable memory modules (e.g., including random access memory, read-only memory, etc.), and an input/output interface. The processing unit fetches and executes instructions stored in the memory modules. The memory modules can also store data used or created by the processing unit as part of executing instructions. The input/output interface allows the server 2 to communicate with devices, systems, and networks external to the server 2. Similarly, it should be understood that the “modules” and “engines” described in the present application can be implemented as software (i.e., instructions) executed by a processing unit to perform particular functionality.
The application server 2 (i.e., the memory modules included in the server 2) stores and provides access to a user administration module 10, an organization administration module 12, a counterparty administration module 14, a master agreement management module 16, an authorization and permissions module 18, a report management module 20, an interfaces module 22, a transaction maintenance module 23, a transaction selection module 24, a collaborative tie-out module 26, a real-time trade matching engine 28, a notification module 30, an invoicing module 32, a dispute management module 34, a credit management module 36, the payment module 46, a document management module 44, a data management engine 6, and a database server 4. It should be understood that the components of the application server 2 may be combined in a different manner than as shown and described in
The user administration module 10 stores and maintains individual user accounts, roles, and permissions for individuals accessing the ECP. The organization administration module 12 stores and maintains organizational information, including but not limited to corporate, banking, and system interface integration configuration information. The counterparty administration module 14 stores and maintains relationship information between the organization and the organization's counterparties. In some embodiments, information maintained by the counterparty administration module 14 is used as system configuration information for the notification module 30, the credit management module 36, the payment module 46, the dispute management module 34, the collaborative tie-out module 26, and/or the invoicing module 32.
The master agreement management module 16 stores and maintains master agreement contract information between the organization and the organization's counterparty. The stored data can include, but is not limited to, invoicing cycle information (e.g., daily, weekly, monthly), invoice creation date (e.g. 10th business day of month), payment due day (e.g. 20th of month (10 days after receipt of invoice)), credit limits, and collateral requirements. In some embodiments, the ECP utilizes master agreement information to customize the creation of the tie-out period, transaction matching, invoice creation, and ECP-generated notifications to participants of the ECP. The ECP can also use master agreement credit limits and collateral requirements in the credit management module 36.
The authorization and permissions module 18 identifies and stores authorizations, permissions, and roles for users of ECP. For example, a participant may have an ECP role of “Invoice Approver” but not have the role of “Payment Disburser.” Accordingly, the user assigned as the “Invoice Approver” may not have the authorization and permission to disburse payments but has the authorization and permission to approve invoices. The authorizations and permissions module 18 also may be configured to determine the amount of authority that a user has to perform a particular function, such as approving invoices. For example, a participant may have the role of “Payment Approver” but only up to a specified amount of the invoice (e.g., authority to approve invoices up to $100,000). Additionally, the authorizations and permissions module 18 may be configured to assign users to specific counterparties so that a user has authority to act in a specific role when working with a specific counterparty. For example, a participant may have the role of “Invoice Approver” when working on transactions with Counterparty D but not be authorized as “Invoice Approver” for any other counterparties. Accordingly, each counterparty can uniquely configure the authority of their authorized users resulting in a unique workflow during the processing of transactions through
The report management module 20 facilitates the generation of printable reports and/or data exports. In some embodiments, the report and exports are stored in the database server 4, which is securely accessible through the data management engine 6. Reports may be produced in printed format or in downloadable data formats. For example, a participant may produce a report of all out-trades with a specific counterparty for a specific tie-out period. The participant may then export this data in a particular format, such as in a Microsoft Excel format.
The interfaces module 22 interfaces ECP to external systems. These systems include, but are not limited to, ETRM systems, transaction confirmation systems, treasury systems, accounting systems, credit management systems, collateral management systems, and depository financial institution systems (payment processing). The interfaces module 22 transmits data to and/or receives information from external systems.
The transaction maintenance module 23 allows a participant to modify transactions including trade transactions, tie-outs, invoices, payments, and disputes in the ECP. For example, in some embodiments, the ECP receives an imported transaction through the interfaces module 22 and updates the transaction on the database using the data management engine 6 and the database server 4. In other embodiments, a participant manually enters the wholesale energy trade transaction modifications online using the transaction maintenance module 23 to modify transactions in the ECP without an import through the interfaces module 22.
The transaction selection module 24 allows a participant to select one or more trade transactions in the ECP and associate the trade transactions. For example, in some embodiments, the transaction selection module 24 is accessed by the collaborative tie-out module 26 to associate trade transactions with a tie-out. In another embodiment, the transaction selection module 24 is accessed by the invoicing module 32 to associate trade transactions with an invoice.
The collaborative tie-out module 26 allows a participant to establish a settlement tie-out between counterparties to financially settle wholesale energy trade transactions. The tie-out period (i.e., the time period to financially settle wholesale energy trades—also sometimes referred to as a delivery period) is determined by accessing the master agreement management module 16 which stores the agreed upon tie-out period between the counterparties which can be, but is not limited to, monthly or some other agreed upon tie-out period.
The trade matching engine 28 performs real-time wholesale energy trade transaction matching of buy-to-sell and sell-to-buy transactions. As transactions are imported or manually entered with the transaction maintenance module 23, the trade matching engine 28 applies an algorithm to identify matching transaction pairs. Transactions that matched are set or stored as “Matched” transactions and transactions that do not match are stored as “Out-Trade” transactions. The trade matching engine 28 can be used within the collaborative tie-out module 26.
The notification module 30 generates notification and/or alert messages when actions are required and/or for informational purposes. Notifications include, but are not limited to, email, text messages, and ECP-viewable messages.
The invoicing module 32 allows a participant to issue an invoice for financial settlement of one or more tie-outs determined by accessing the collaborative tie-out module 26. Each invoice contains on or more tie-outs resulting in the creation of a “net” invoice between counterparties. The invoice details (e.g., including due date, payment method, and associated financial institution information) can be determined by accessing the master agreement management module 16 that stores the agreed upon invoicing information including due dates for invoices.
The dispute management module 34 allows a participant to manage disputes with one or more counterparties. For example, in some embodiments, the transaction selection module 24 is accessed by the dispute management module 34 to open a dispute with selected wholesale energy trade transactions that are out-trades. In another embodiment, the dispute management module 34 accesses the invoicing module 32 to open a dispute with an invoice. In yet another embodiment, the dispute management module 34 accesses the payment module 46 to open a dispute with a payment.
The credit management module 36 allows a participant to manage credit exposure with counterparties. For example, in some embodiments, the credit management module 36 determines the credit exposure to a counterparty by calling the transaction selection module 24 (e.g., to determine transaction activity with the counterparty and calculate the associated credit exposure). In another embodiment, the credit management module 36 accesses the master agreement management module 16 (e.g., to access collateral communication information) to notify a counterparty exceeding the credit limit. In some embodiments, the credit management module 36 generates such a collateral call notification by providing information to the notification module 30.
The document management module 44 generates and stores ECP-generated documents and attached uploaded supporting documents. The document management module 44 also provides custom document templates and the ability to upload supporting documents that can be associated with an ECP-generated document. For example, in some embodiments, the ECP generates an invoice from an organization custom template. The user then uploads scanned supporting documentation and attaches these documents to the ECP-generated invoice.
The data management engine 6 stores and retrieves data from the database server 4. The data management engine 6 also verifies access authorization to data by calling the user administration module 10 to determine the authority level of a user.
The database server 4 facilitates the physical secure storage of data. In some embodiments, data is stored in a real-time database for very fast and low-latency data access. In other embodiments, the data is stored in a historical reporting database, which is not used for real-time access. Rather, the historical reporting data can be used to perform historical reporting which is not time sensitive.
As noted above, the security and verification module 8 verifies organizations and user participants that are authorized to access the ECP. Participants 50 can include, for example, Operational Settlement Analysts, Credit Analysts, Financial Accounting Analysts, Risk Analysts and Traders for the organization, and each counterparty organization on the ECP. Although not shown in
A participant 50 can use a computing device (e.g., a personal computer, a laptop computer, a tablet computer, a smart phone or device, etc.) to connect to the ECP over the network 48. The participants 50 can access the application server 2 to use the various modules, managers, and engines to manage the electricity wholesale transaction payment process. In some embodiments, the ECP can connect all participants to a web-based, real-time system, organize transactional information for a tie-out period, facilitate a transaction tie-out process, facilitate electronic submittals, reviews, and approval of invoices, and manage payment of invoices.
As illustrated in
The process illustrated in
An invoicing process 57 is also illustrated in
The payment execution process 58 is performed by the payment module 46. The payment execution process 58 performs payments (i.e., ACH, wire transfers, etc.) and distributes the records of the payments received for export to a financial accounting system of record 52. As described in more detail below, handling the payments through the ECP reduces credit exposure by the credit management process 66.
As illustrated in
The credit management process 66 is performed by the credit management module 36. The process 66 allows bilateral transaction counterparties to track and manage credit exposure and payment history. The process 66 also alerts participants 50 as margin thresholds approach or are exceeded, necessitating a collateral call. The credit management process 66 facilitates the on-line collaborative credit review between two bilateral transaction counterparties, as well as the issuance of a collateral call, if necessary. The credit management process 66 also supports the creation of an accounts receivable invoice in the amount of the collateral call which is processed in the invoicing process 57.
After the transaction details are received, a tie-out period is created. In some embodiments, a settlement analyst from one of the bilateral transaction counterparties (e.g., “Settlement Analyst A” representing “Participant A”) defines a tie-out period (at block 102). For example, Settlement Analyst A can define a tie-out period by selecting the date range for which delivered transactions are tied out and included on the invoice. The tie-out period may coincide with the invoice or “billing” period or may occur on a different schedule. Alternatively or in addition, the ECP can be configured to automatically credit a tie-out period (e.g., based on configuration data established by the parties and/or one or more agreements between the parties as stored in the master agreement management module 16).
Based on the specified tie-out period, the ECP creates a tie-out period workspace for the defined tie-out period. As described in more detail below, the tie-out period workspace provides each counterparty with both a shared and a proprietary view of the transactional data included in the tie-out period workspace. The shared view presents public transactional information. The proprietary view presents proprietary data (e.g., data not to be shared with the counterparty).
The Settlement Analyst A also selects transactions to be included in the collaborative tie-out process for the defined tie-out period using a create tie-out screen 103 (see
After the Settlement Analyst A selects the transactions for the tie-out period and/or selects the tie-out period, the ECP generates a tie-out notification 110 (see
Accordingly, the transaction selection process 61 establishes the transactions that are included in the collaborative tie-out process 56 for an established tie-out period. Based on configuration information established using the counterparty administration module 14 and the master agreement management module 16, the ECP performs the transaction selection process 61 in an automated, partially automated, or manual fashion.
After the trade matching engine 28 performs the matching algorithm, the ECP presents the participants with a shared, collaborative, view of the tie-out period's matched transactions and the unmatched out-trade transactions using a view tie-outs screen 126 illustrated in
For example, the tie-out collaborate screen 127 presents a view of the matched transaction data of each participant's public and proprietary transactional data and enables either party to reject or approve the ECP matched transactions and enter transaction-specific public and proprietary comments. For example, either Settlement Analyst can override or reject an ECP-matched transaction by highlighting the matched trade transactions and selecting a “Reject Matched Trade” selection mechanism 128 in the tie-out collaborate screen 127 (see
When the ECP generates an out-trade transaction, a Settlement Analyst can also decide to accept the bilateral counterparty's view of the transaction by selecting the “Approve Trade” selection mechanism 138 (see
The ECP calculates and presents transaction totals (amounts and volume) for the matched transaction list to both parties. The ECP can also calculate and present a net amount due to the payee (i.e., the bilateral counterparty to whom a payment is due). In some embodiments, after all transactions for the tie-out period are matched (at block 150), both participants accept and approve the collaborative tie-out period by selecting a “Close Tie-Out” selection mechanism 152 in the tie-out collaborate screen 127 (at block 153). In other embodiments, even if not all of the transaction for the tie-period are matched, the ECP can allow the participants to approve the collaborative tie-out period and the ECP can automatically process each out-trade transaction included in the tie-out and creates a dispute that is processed during the dispute management process 68. Upon selecting the “Close Tie-Out” selection mechanism 152, the ECP designates the tie-out period as “invoice ready.” In some embodiments, the participants continue to process transactions and reject matched transactions until both parties agree to all transactions or until a user configurable invoice date occurs (at block 155), at which time ECP automatically designates the tie-out period as “invoice ready” and automatically processes each out-trade transaction included in the tie-out and creates a dispute that is processed during the dispute management process 68.
When the tie-out period is “invoice ready,” the ECP sets the status of each approved matched transaction as “Eligible for Invoicing” (at block 156). The ECP also sends a tie-out ready for invoicing notifications 160 (see
Returning to block 122 illustrated in
For example, Settlement Analyst A can select several hourly power trade transactions that the trade match engine 28 set to “Out-Trade” because one or more data attributes of each trade provided by counterparty B, for example the volume or price information, did not match the same data attribute information provided by counterparty A for the same trade. After revising transaction details for the out-trades in party's A transaction system of record 51, Settlement Analyst A can select the “Request Trade Revision” selection mechanism 176 (see
If an out-trade cannot be reconciled and matched during this tie-out period (at block 166), a dispute for the transaction can be established (at block 180). In particular, a party can set the transaction as “disputed” by selecting a “Dispute Trade” selection mechanism 182 (see
Accordingly, as illustrated in
Upon either manual or automatic execution, the ECP creates an invoice that includes the transactions for a specific bilateral counterparty and defined tie-out period (at block 192 in
Both parties can access the invoice information through a view invoices screen 198 (see
The payor (e.g., an Invoice Reviewer) can examine the invoice summary and the detailed transactions in the invoice collaborate screen 200 (at block 202). The payor can also prepare the invoice for the tie-out period, such as by attaching supporting documents via the document management module 44 and indicating any potential disputed transactions (at block 204). The payor can then select a “Pay” selection mechanism 205 (see
In some embodiments, if there is a disputed transaction within invoice information (at block 220), a party (e.g., the Payor Disbursement Approver) can select the disputed transaction and select a “Request Trade Revision” selection mechanism 222 (see
The ECP can also generate an open dispute notification 232 to both participants as illustrated in
For example, the ECP presents each participant a view of disputed transactions with one or more counterparties in a view disputes screen 238 illustrated in
If the parties agree to resolving a disputed transaction (at block 246), one or both parties (e.g., the disputing participant) can select a “Close Dispute” selection mechanism 248 (see
If a disputed transaction is not resolved (at block 246), the parties (e.g., the Settlement Analysts) can continue reviewing transactional information to reconcile their differences. The ECP can be configured to send periodic reminder notifications of open disputes.
Accordingly, based on configuration information established using the counterparty administration module 14 and the master agreement management module 16, the ECP can perform the dispute management process 68 in an automated, partially automated, or manual fashion.
In the bilateral financial accounting system workflow, the payment module 46 prepares an interface file containing the payment information for one or both counterparties and accesses the interfaces module 22 to update counterparties' financial accounting systems of record 52 with payment information. The payment information can include but is not limited to invoice information and invoice line-items. Payment is then made by the counterparty using their existing financial payment system.
In the manual payment workflow, a Payment Clerk accesses the invoices eligible for invoicing through a create payment screen 340 (see
In some embodiments, a payment with a “pending” status must be approved by a second user or role of the party with the authority to approve payments as determined by the user administration module 10 (e.g., a Payment Reviewer). The Payment Reviewer can access “pending” payments and select an “Approve Payment” selection mechanism 349 (see
In some embodiments, in addition to approval, a Payment Reviewer can reject a payment by selecting a “Reject Payment” selection mechanism 352 illustrated in
Accordingly, based on configuration information established using the counterparty administration module 14 and the master agreement management module 16, the ECP can perform the payment execution process 58 in an automated, partially automated, or manual fashion.
To manage credit information, the ECP can present the participants with a shared or collaborative view in a credit collaborate screen 404 as illustrated in
The ECP updates the credit exposure information presented in the credit collaborate screen 404 based on imported data from the parties and transaction processing during the transaction selection process 61, collaborative tie-out process 56, the invoicing process 57, the dispute management process 68, the invoicing process 57, and/or the payment execution process 58. For example, in some embodiments, the ECP continuously calculates the total credit amount between the counterparties by summing the expected financial exposure that exists in trade transactions, tie-outs, invoices, disputes and payments as if the counterparty were to immediately cease doing business. The ECP can also be configured to calculate, based on a configuration in the master agreement management module 16, the total credit amount between a single counterparty and all or a subset of counterparties 50 in the ECP by summing the expected financial exposure that exists across trade transactions, tie-outs, invoices, disputes and payments as if the counterparty were to immediately cease business with all participants 50. A party may also establish a credit threshold limit between two or more bilateral counterparties (e.g., entered using a create counterparty credit screen 406 as illustrated in
If a participant 50 is approaching a credit limit threshold or other user-defined limits (at block 408 in
As illustrated in
If a collateral call is desired (at block 416), the Credit Analysts can determine if the collateral call is met by engaging in an offsetting transaction for which the counterparty buys back an existing sale or sells an existing purchase of forward bilateral transactions to satisfy the collateral call (at block 418). If an offsetting transaction is used, one of the Credit Analysts notifies the respective Risk Analysts to enter revised transaction details in respective transaction systems of record 51 (at block 420). In some embodiments, the ECP also notifies the respective Risk Analysts to enter the offsetting transaction details in their respective transactions systems of record and to add clarifying comments to the transaction record to maintain an audit log (at block 422). The Risk Analysts update the transactional information in the transaction system of record 51 (at block 424). After the transaction data is revised, the transaction is re-imported from the transaction system of record (e.g., via the interfaces module 22 or via manual entry). The data can then be loaded and selected into the appropriate tie-out period workspace at which time ECP includes the transaction in the real-time match process described above.
If a collateral call is desired (at block 416) and some or all of the call amount is being met with additional margin (at block 418), a Credit Analyst can select an “Issue Collateral Call” selection mechanism 430 as illustrated in
Alternatively or in addition, if a Credit Analyst determines that a credit limit adjustment should be made, the Credit Analyst selects the “Revise Credit Limit” selection mechanism 438 illustrated in
Alternatively or in addition, if a Credit Analyst determines that a relationship should be suspended, the Credit Analyst selects a “Suspend Counterparty Relationship” selection mechanism 442 illustrated in
Accordingly, based on configuration information established using the counterparty administration module 14 and the master agreement management module 16, the ECP can perform the credit management process 66 in an automated, partially automated, or manual fashion.
Thus, embodiments of the invention provide, among other things, systems and methods for conducting a wholesale energy transaction settlement process. It should be understood that the ECP can be configured to perform one, a subset, or all of the functions described above. Accordingly, the ECP can be configured to meet the requirements of particular counterparties. It should also be understood that although particular participant roles have been provided in the above descriptions regarding the functionality performed by the ECP, the functionality may be performed by other user roles within a particular participant.
Various features and advantages of the invention are set forth in the following claims.
标题 | 发布/更新时间 | 阅读量 |
---|---|---|
证券市场量化投资策略的精准回测与评估系统及方法 | 2020-05-14 | 1014 |
金融衍生品大数据分析、交易与风险管理系统及方法 | 2020-05-21 | 619 |
基于数字货币的跨境支付清算系统和跨境支付方法 | 2020-05-23 | 349 |
一种训练方法、特征提取方法、装置及电子设备 | 2020-05-08 | 217 |
一种电力市场交易的履约保函的计算方法及装置 | 2020-05-14 | 426 |
资产数据处理方法、装置、计算机设备和存储介质 | 2020-05-15 | 762 |
交易风险识别方法、装置和计算机系统 | 2020-05-13 | 328 |
一种基于半监督图神经网络的智能可疑交易监测方法 | 2020-05-12 | 875 |
一种供应链金融业务中对融资企业的风险控制方法及系统 | 2020-05-11 | 104 |
Collateralized lending using a central counterparty | 2020-05-25 | 475 |
高效检索全球专利专利汇是专利免费检索,专利查询,专利分析-国家发明专利查询检索分析平台,是提供专利分析,专利查询,专利检索等数据服务功能的知识产权数据服务商。
我们的产品包含105个国家的1.26亿组数据,免费查、免费专利分析。
专利汇分析报告产品可以对行业情报数据进行梳理分析,涉及维度包括行业专利基本状况分析、地域分析、技术分析、发明人分析、申请人分析、专利权人分析、失效分析、核心专利分析、法律分析、研发重点分析、企业专利处境分析、技术处境分析、专利寿命分析、企业定位分析、引证分析等超过60个分析角度,系统通过AI智能系统对图表进行解读,只需1分钟,一键生成行业专利分析报告。