Note: Descriptions are shown in the official language in which they were submitted.
CA 02826953 2013-09-16
[169-21 Sam ir Chaw la
Cross-reference to Related Patent Application
This application claims priority from U.S. Provisional Application No. 61/
702,148 filed on
September 17, 2012, the disclosure of which is incorporated herein by
reference in their entirety.
Title
Collateralized Cash Clearing System and Method
Field
The field generally relates to fulfilling obligations between parties.
Background
Transactions through the SWIFT network for cross currency trades typically go
through the
central bank of the currency used in the transaction. For example, a payment
instruction issued
through the SWIFT network for a payment in Mexican Pesos will go through the
Mexican
Central Bank if the instruction originates from a US-based bank.
These transactions, however, cannot be completed if the currency's central
bank is closed. If the
settlement of a cross currency trade occurs during a time of the day when that
respective
currency cannot be paid, the payor must wait until the currency's central bank
reopens.
In other situations, transactions may fail to complete if there is
insufficient quantity of a specific
currency to settle a cross currency transaction.
In scenarios such as the ones described above, risk is introduced to the
transaction that must
either be borne by the payor or the receiver party. In extreme circumstances
such as natural
disasters, economic collapse, or national collapse, this may trigger a domino
effect of failed
trades, putting both the parties at risk.
1/38
CA 02826953 2013-09-16
069-21 Sani ir 'haw la
Summary
What is provided are systems and computer-implemented methods for fulfilling
cross currency
obligations between a plurality of parties over a computer network, the
obligations guaranteed by
the independent third party. By decoupling the fulfillment of cross-border
transactions from the
operating hours of each currency's central bank, risks to the parties and to
the financial system
can be reduced. Furthermore, by requiring that party's deposit sufficient
collateral to cover their
payment transactions, payments can be guaranteed. That is, the collateral can
be liquidated if the
party is unable to fulfill its obligation. This allows the payment transaction
to be fulfilled
regardless of the condition of the payor party.
In one aspect, a Collateralized Cash Clearing System (CCCS) is provided. This
system
guarantees and fulfills cross currency obligations between parties at any time
of the day. In an
example embodiment, the system comprises a data store configured to store
transactional, client,
and system data. The system also has a server that has one or more data
processors. The data
processors are configured to process payment transactions in one or more
currencies from one or
more clients, apply risk management filters to the payment transaction, store
the payment
transactions in the data store as incoming and outgoing pending payment
transactions, clear the
transactions at a set time using transaction data stored in the data store by
offsetting each party's
incoming and outgoing payment transactions for each currency so that each
party has a net
positive or net negative balance for each currency; provide status reports to
clients on demand;
notify clients of a deposit requirement when the client has a net negative
balance; and liquidate at
least a portion of the client's collateral to cover the deposit requirement if
the deposit
requirement is not completed before a timer expires. The system also has one
or more clients
configured to initiate payment transaction requests and to requests status
reports from the server.
A CCCS is an interbank payment clearing system accessible via an online and
secure network
that is used by banks and other financial institutions, called clearing
members. A CCCS clears
clearing member to clearing member cash payments of the various currencies
that have
been approved by the system. Cash payments are guaranteed and honored by a
CCCS by
requiring all clearing members to deposit collateral in their clearing
accounts that secure the
2/38
CA 02826953 2013-09-16
l 69-2 Sam ir Chaw la
value of their outgoing payments. On a set schedule, the system is "cleared"
meaning that the
monies of all currencies are to be be paid/received on the system are netted
together and
physically paid in and out to clearing members. After the settlement process,
all money
that has been physically paid/received nets to a balance of zero. If a
clearing member were to
default on an obligation to pay during the settlement process their collateral
would be
liquidated and converted to the payments that were defaulted then paid out to
the
receiving clearing member(s). There would also be penalties and/or legal
action against a
clearing member who defaults during a settlement process.
In another aspect, computer-implemented methods are provided for fulfilling
obligations
between a plurality of parties over a computer network. In an example
embodiment, a client that
is controlled by a first party of the plurality of parties is provided. The
party can use the client to
initiate a payment transaction request, in a single currency, to a second
party of the plurality of
parties. This payment transaction request is then sent to a server that is
controlled by an
independent third party. The payment transaction request is accepted by the
server. The server
converts the first party's payment transaction to the first party's base
currency. The server then
determines whether the first party has sufficient margin balance to cover the
payment transaction
request. The server does this by determining whether the payment transaction
request will cause
the first party's margin balance to fall below a threshold value. Once
approved, this transaction is
stored as an uncleared outgoing payment transaction for the first party and as
an uncleared
incoming payment transaction for the second party in the data store. At a time
determined by the
server, any uncleared payment transactions are cleared. The clearing process
involves offsetting
each party's outgoing and incoming payment transactions for each currency so
that each party
has a net positive or net negative margin balance for each currency. Those
parties with a negative
margin balance must deposit the negative margin balance before a predetermined
time frame set
by the server. Furthermore, the net of all uncleared incoming and outgoing
payment transactions
for all parties is zero. The margin balance is determined by adding a total
collateral value of the
party with the total incoming payment transaction value for the party in all
currencies, converted
to the party's base currency, and subtracting the total outgoing payment
transaction value for the
party in all currencies, converted to the party's base currency. If a party
having a negative margin
balance fails to deposit the balance within the predetermined time frame, the
party's collateral is
3/38
CA 02826953 2013-09-16
1169-21 s;amir Chaw la
liquidated to cover the net negative balance.
In another example embodiment, the pool of transactions for all parties is
netted before
transactions are fulfilled. This allows for transactions to offset, reducing
the overall currency
transfer requirement and mitigating risk for the system. This example
embodiment also allows
parties to engage in financial transactions at any time of the day.
In another aspect, a computer implemented method for fulfilling obligations
between a plurality
of parties over a computer network is provided. In this example embodiment, on
a client
controlled by a first party of the plurality of parties, a party can initiate
a payment transaction
request, in a single currency, to a second party of the plurality of parties.
The payment
transaction request is then sent to a server controlled by an independent
third party to the
plurality of parties. The server then accepts payment transaction requests
from the client machine
and saves the transactions as uncleared incoming and outgoing payment
transactions in a data
store. At a time determined by the server, all uncleared payment transactions
from the plurality of
parties are cleared.
In another aspect, a system for fulfilling obligations between a plurality of
parties over a
computer network is provided. The system comprises a data store configured to
store
transactional, client, and system data. The system also comprises at least one
server configured to
process payment transactions in one or more currencies from one or more
clients; store the
payment transactions in the data store as incoming and outgoing pending
payment transactions;
and clear the transactions at a set time using transaction data stored in the
data store by offsetting
each party's incoming and outgoing payment transactions for each currency so
that each party
has a net positive or net negative balance for each currency. The system also
comprises one or
more clients configured to initiate payment transaction requests.
In yet another aspect, a computer implemented method for fulfilling cross-
currency payment
obligations between a plurality of parties over a computer network is
provided. In this example
embodiments, on a client controlled by a first party of the plurality of
parties, a party can initiate
a payment transaction request, in a single currency, to a second party of the
plurality of parties.
4/38
CA 02826953 2013-09-16
[169-21 Sam ir Chaw la
The payment transaction request is then sent to a server controlled by an
independent third party
to the plurality of parties. The server then accepts payment transaction
requests from the client
machine and saves the transactions as uncleared incoming and outgoing payment
transactions in
a data store. At a time determined by the server, all uncleared payment
transactions from the
plurality of parties are cleared.
Brief Description of the Drawings
FIG 1 is a system diagram of an example embodiment Collateralized Cash
Clearing System
(CCCS).
FIGS 2 to 3 are flowcharts illustrating an example embodiments of the clearing
process.
FIGS 4 and 5 are flowcharts illustrating an example embodiment of the
collateral deposit and
transaction approval process.
FIGS 6 and 7 are flowcharts illustrating an example embodiment of the payment
order and
payment order transaction approval process.
FIG 8 is a flowchart illustrating an example embodiment of the margin balance
update process.
FIGS 9 to 29 show an example embodiment client interface as shown on a client
machine for the
Collateralized Cash Clearing System (CCCS).
FIGS 30 to 48 show an example embodiment system administrator interface as
shown on a client
machine for the Collateralized Cash Clearing System (CCCS).
FIG. 49 shows an example embodiment generic computer device.
Definitions
5/38
CA 02826953 2013-09-16
169-21 Swiiir CilaW la
Asset: A liquid security acceptable by a CCCS to be deposited by a clearing
member via a
securities depository to a CCCS in their clearing account and that has margin
value.
Approved Currency: A currency that has been approved by a CCCS to allow
guaranteed
payments amongst its clearing members and to settle during its settlement
process.
Base Currency: The currency rate a on a CCCS that a party can adjust which
reflects the
displayed margin figures of an aforementioned reference. That is, the member
party's default
currency
Clearing Member: A bank, broker or financial institution that has applied,
been vetted and
been approved to conduct transactions on a CCCS by the CCCS.
Clearing Account: A clearing member's account with a CCCS.
Clearing Balances: The balance of funds a clearing member will pay (negative
clearing
balance) and receive (positive clearing balance) for each applicable approved
currency during the
settlement process.
Clearing Window: An identifiable singular channel of a CCCS that is pre-set to
have its
settlement process at a certain time. Multiple clearing windows can exist with
different
times that the settlement process is run. Each clearing window is margined
separately.
Collateral: A broad term that is a reference to Assets, Hard Cash, Soft Cash,
Security or
Commodity redeemable for value by a Collateralized Cash Clearing System in
partial or by
whole, individually or combined that has margin value in and by a CCCS.
Hard Cash: Physical cash deposited to a CCCS by a clearing member that is held
in their
clearing account and has margin value. Soft Cash: Incoming guaranteed payments
that are
held in a clearing member's clearing account and has margin value. Soft cash
is
6/38
CA 02826953 2013-09-16
1169-21 Salim Chaw la
calculated by summing the value of a clearing member's positive clearing
balances in the party's
base currency.
Guaranteed Payment: A transferable guarantee that a payment in an approved
currency will
be honored by the CCCS during its settlement process. It is instructed in the
CCCS by
a clearing member to guarantee a payment to another clearing member. The CCCS
takes
custody of the paying clearing member's collateral in order to honour the
guaranteed
payments in case of default. Therefore a guaranteed payment is not a physical
or official
exchange of any monies.
Margin Requirement: The margin value of all outgoing guaranteed payments in
all
approved currencies added together in the party's base currency. Margin
requirements are
calculated by summing the value of a clearing member's negative clearing
balances and
displaying it in the party's base currency.
Margin Balance: The value representing a clearing member's total margin value
minus the
margin requirement as valued by a CCCS in the party's base currency.
Margin Value: The total value of a party's hard cash, soft cash, and asset
collateral minus any
conversion, or risk management adjustments, in the party's base currency.
Party: An approved member of the CCCS that is either a payor or receiver of
the proceeds of a
transaction.
Settlement Process: The moment in time or times (determined by a CCCS) when
guaranteed payments are honored by the CCCS. The CCCS may net all payments
occurring in
this window to streamline payment. All clearing members pay off all negative
clearing
balances and receive their positive clearing balances from a CCCS neutralizing
all clearing
balances, margin requirements and soft cash.
System Administrator: An employee, officer, authorized personnel or
virtual/automated entity
7/38
CA 02826953 2013-09-16
[ 1 69-2 3 Sam ir Chavla
internal or external of a CCCS that has administrative access to a CCCS.
User: Any system administrator or authorized personnel of a clearing member
that has access to
the CCCS.
Detailed Description
The systems and methods provided allow parties to fulfill obligations through
an independent
third party that guarantees that the cross currency obligations will be
fulfilled. In an example
embodiment, the CCCS guarantees and fulfills cross currency obligations. An
example
embodiment of how the CCCS is used is described in the simple scenario between
two CCCS
member parties provided below.
First, the payor party deposits collateral with the CCCS. An example
embodiment of how the
CCCS might handle a collateral withdrawal or deposit transaction is provided
in FIG. 4. In this
example embodiment, collateral may be any combination of cash, soft cash, or
any approved
security, government debt, or bond. Generally, easily liquidated assets are
preferred as collateral.
This collateral is used to protect the CCCS by ensuring that sufficient funds
will be available if
the payor party fails to meet their margin deposit obligations. As will be
discussed later, if the
payor parties fails to meet their margin deposit obligations, the collateral
is liquidated and used
to cover the outstanding negative clearing balance.
The transaction is then processed by the system 41. The step of processing can
include adjusting
the collateral deposit amount to account for variables such as, but not
limited to, risk, currency
conversion, or regulations. For example, if the collateral is not in the payor
party's specified base
currency, then the value of the collateral will be converted to be in the base
currency. This
deposited amount, subject to adjustments during processing 41, represents the
party's margin
balance. The CCCS 's records are then updated with the transaction data.
In an example embodiment shown in FIG 6, the payor party can then initiate a
payment
8/38
CA 02826953 2013-09-16
69 21 Samir Chaw la
transaction 61 to a receiver party of an amount up to, but not exceeding, the
value of the margin
balance. In this example embodiment, the CCCS will check to ensure that the
payor party has
sufficient margin to guarantee payment 62.
In some example embodiments, the payment transaction can be in any one of a
CCCS-approved
basket of currencies regardless of the currency of the collateral on deposit.
In this example
embodiment the CCCS will convert the transaction amount to the payor party's
base currency
when determining whether the payor party has sufficient margin to guarantee
payment 62.
When the CCCS has determined that the payor party has sufficient collateral to
complete the
transaction the CCCS processes the transaction 63. During processing, the
outgoing payment
transaction amount is deducted from the payor party's clearing balance in the
particular currency
of the transaction. The payor's margin balance is also updated to reflect the
payment transaction
amount, converted to the payor's base currency.
In some example embodiments, during processing this outgoing payment
transaction is paired
with an incoming payment transaction, or receipt transaction, to the receiver
party. This receipt
transaction may be automatically generated by the CCCS. This receipt
transaction updates the
receiver party's clearing balance by adding the payment transaction to the
receiver party's
clearing balance for that currency. Similarly, the receiver party's margin
balance is adjusted by
adding the payment transaction amount, in the receiver party's base currency,
to the receiver
party's margin balance. In some example embodiments, this amount may be
categorized as "soft
cash", to distinguish it from hard cash or asset margin value. In other
example embodiments, no
distinction may be made The receiver party may then use this margin balance to
initiate its own
payment transactions that are unrelated to this transaction currently being
described.
In some example embodiments, as shown in FIG 7, the payment and receipt
transactions are not
processed until the transactions have been confirmed. That is, the payor and
receiver's margin
and collateral balances are not updated until the transaction is approved. In
some example
embodiments these transaction requests are automatically processed if the
payment criteria
complies with defined risk management policies. In other example embodiments a
system
9/38
CA 02826953 2013-09-16
1169-2] Sam ir Chaw la
administrator may need to confirm these transactions. In a non-limiting
example, the system will
approve a payment transaction when it has been determined that the payment
transaction will not
cause the payor party's margin balance to become negative. Other conditions
may also be used to
approve or reject a payment transaction. For instance, a member's history of
transaction default,
or a payment transaction in an amount not typical for that member may also be
grounds for
rejecting the transaction.
In another example embodiment, payment transactions can be modified by the
payor party at any
time prior to the beginning of the clearing period. For example, in some
circumstances the payor
party may wish to edit the amount of the transaction, or to cancel the payment
transaction
completely. As long as the clearing process has not started, the payor party
is free to edit the
transaction. If the transaction is modified, the system will need to re-
confirm the transaction. A
corresponding change is made to the receiving transaction so that the change
is reflected in both
transactions.
In some example embodiments, interest rates are periodically applied to any
margin, clearing, or
collateral balances. In an example embodiment, the accrued interest or
interest expenses are
applied to the party's margin and or clearing balance. In some example
embodiments the interest
rate is set manually by a system administrator. In other example embodiments,
the interest rate is
obtained from a secure and trusted data source. In those embodiments where
interest is applied to
any collateral or margin balances, the interest rate will affect the party's
margin and clearing
balance. For example, in the example embodiment where interest is applied, the
party's margin
and clearing balance will be adjusted daily. In an example embodiment,
interest applied to
negative clearing balances will be the same as interest applied to positive
clearing balances. This
way, all interested collected from negative clearing balances will be applied
to positive clearing
balances for a net interest of zero (0). In other example embodiments the
system may levy a
transaction or administrative fee so that the net interest is not zero (0).
The frequency at which interest is applied will depend on the implementation
of the system. In
this example embodiment, interest may be applied daily, weekly, monthly, or
yearly. A skilled
person would understand that other interest calculation windows could be used
without departing
10/38
CA 02826953 2013-09-16
[169-21 Sam ir Chaw la
from the scope of this disclosure.
The system then clears the transactions. Example embodiments of the clearing
process are
illustrated in FIGS 2 and 3. In an example embodiment, the clearing process
begins at a
predetermined time set by the system. In some example embodiments, the
clearing window may
be periodic. That is, clearing windows are regularly scheduled on intervals
such as, but not
limited to, every minute, every half hour, hourly, every half day, daily,
every few days, weekly,
every few weeks, monthly, every few months, or yearly. In other example
embodiments, the
system may be configured to allow for clearing windows to be initiated
manually so that
transactions may be cleared as necessary. In yet another example embodiment, a
clearing
window may be scheduled for a specific time and date.
Once the clearing process has begun the payor party cannot modify existing
transactions. During
the clearing period the transactions are finalized and obligations are
fulfilled. In an example
embodiment, all paired transactions are committed during the clearing process.
In this example
embodiment, since each payment transaction has an equivalent receipt
transaction the net of all
paired transactions should be 0. That is, the amount paid by a payor party
should equal the
amount received by the receiving party such that the net amount of the payor
and receiving
transactions is zero (0). Thus, at the end of a clearing period, the net
balance system-wide for all
payment and receipt transactions in all currencies should be zero (0). During
the clearing
process, the system may modify the payment transaction, the receiving
transaction, or both, to
adjust the transaction based on market conditions.
In some example embodiments, the amount a party pays or receives in a
particular transaction
may be offset by an amount the party pays or receives in another, unrelated,
transaction. For
example, in an example embodiment a party may be involved in multiple payment
transactions
with different parties. In some transactions, the party may be a payor. In
other transactions, the
party may be a receiver. When the clearing process begins, rather than
fulfilling each transaction
separately, the CCCS may net all of the party's payment and receipt
transactions for one or all
currencies. For instance, if party A receives $10 USD from party B USD, and
party A pays party
C $10 USD, the final net clearing amount for party A for all transactions in
USD is $0.
11/38
CA 02826953 2013-09-16
1169-21 Sanur Chaw la
In an alternate mixed currency example, positive clearing balances in one
currency may be used
to offset negative clearing balances in another currency. For instance, if
clearing balances for a
party are positive $10 USD and negative $11 CAD, the CCCS may convert some or
all of the
$10 USD to cover the $11 CAD negative clearing balance. In this example
embodiment,
assuming a USD to CAD exchange rate of 1:1.1, the final clearing balance of
the party would be
$0. This may be used in highly traded currencies such as the USD, CAD, Yen or
Euro.
As is shown in FIGS 2 and 3, in another example embodiment, when the clearing
process
completes, the payor party is requested to deposit the outstanding negative
clearing balances for
each applicable approved currency, subject to any additional amounts for risk
management
purposes, to the CCCS so as to cover the payment amount.
If the payor party deposits the outstanding margin amount within the
prescribed window, then the
payor's margin balance resets to zero (0). If the payor still has collateral
in the system, the payor
may initiate another payment transaction up to the value of the collateral,
subject to any risk
management adjustments.
In other example embodiments the payor party may be requested to deposit part
or all of the
transaction amount, in the transaction currency, to the CCCS before the
clearing period begins.
In some example embodiments this may be necessary to ensure that the receiver
receives
payment immediately after the clearing process completes.
In yet another example embodiment, the system may have sufficient currency
reserves to fulfill
the payment transaction before the payor deposits the full transaction amount
in the CCCS. In
this example embodiment, the CCCS may levy a fee, interest, or penalty on the
payor for this
service.
As is also shown in FIGS 2 and 3, if the payor fails to deposit the amount to
the CCCS in the
allotted time frame, then the payor party is determined to be in default. if
the payor party is
determined to be in default, the system liquidates the payor party's deposited
collateral and uses
12/38
CA 02826953 2013-09-16
I 69-2] Sam ir Chaw la
the proceeds to cover the outstanding margin amount. Amounts may be deducted
from the
proceeds of the liquidation to pay for penalties, service fees, currency
conversion, and risk
management.
In this example embodiment, during the clearing process the receiving party
will receive their
positive clearing balance, subject to any amounts deducted for risk management
purposes. In
some example embodiments, the amount will remain in a holding account until
the receiver party
requests payment. In alternate example embodiments, this received amount may
be added to the
receiving party's collateral so that the receiving party can initiate payment
transactions. In other
example embodiments, the amount can be transferred to a third party bank
connected to the
system. In yet another example embodiment, the amount will be transferred to
the clearing
member's possession.
In some example embodiments, a collateral withdrawal transaction must be
approved by the
system before a party can withdraw collateral from the CCCS. In an example
embodiment shown
in FIGS 4 and 5, any collateral withdrawals are subject to the approval of the
CCCS. In some
example embodiments, the system may automatically approve the transaction if
the withdrawal
amount does not cause the party's margin balance to become negative. In
another example
embodiment a system administrator of the CCCS may be required to manually
review and
approve the transaction. In this example embodiment, any collateral withdrawal
requests that
result in a negative margin balance will be rejected.
In some example embodiments the margin balance, margin value, and payment
transaction
amounts may be adjusted by the CCCS without the participation of the parties
both before and
after the clearing process. In this example embodiment as shown in FIG 8,
amounts may be
adjusted for risk management purposes or when currencies are exchanged. If at
any time a
party's margin balance becomes negative due to these adjustments, the party
will be requested to
deposit additional collateral.
In an example embodiment risk management practices are employed throughout
every
13/38
CA 02826953 2013-09-16
[169-2] Samir Chawla
transaction to maintain the stability of the CCCS. These risk management
practices ensure that
the system controls sufficient capital to guarantee all outstanding payments.
These risk
management practices are adjustable to account for geopolitical, economic,
financial, or
environmental instability. For example, in some example embodiments the value
of a party's
collateral, currency, or payment may be reduced to account for various risk
factors. This is
commonly termed a "haircut". In another example embodiment, limits may be
placed on the
asset, asset class, or foreign currency that can be deposited with the system
for collateral. This
can allow for diversification in the system or to prevent an excess of
volatile foreign currency
from destabilizing the system.
In some example embodiments, risk management filters are used to implement
risk management
practices in the CCCS. In this example embodiment, risk management filters are
applied to each
transaction in the system. These filters can be tuned automatically or
manually by a system
administrator of the CCCS. For instance, the system may increase the haircut
applied to a
transaction of a particular currency if the currency is unstable.
Due to the fluctuating nature of foreign exchange rates, the system will
adjust a party's margin
value accordingly if confirmed payment or receipt transactions are made in a
currency that is not
the party's base currency. In some example embodiments these adjustments are
made in real
time. In other example embodiments, these adjustments are only made when
transactions are
being processed. Furthermore, in some example embodiments the foreign exchange
rate for all
currencies are manually entered by a system administrator. In other example
embodiments the
foreign exchange rates for each currency are obtained from a secure and
trusted data source.
In another example embodiment of the present disclosure, a computer
implemented method and
system are provided for performing the method provided above. In this example
embodiment, as
shown in FIG 1, one or more servers 1 and a plurality of client machines 2 are
provided. The one
or more servers 1 are independent of the parties and are used to fulfil the
obligations, among
other things. The parties to the obligations, that is, the payor and receiver
parties, use the clients
2 to initiate transactions such as, for example, collateral or clearing
balance deposits.
14/38
CA 02826953 2013-09-16
69-21 Sam ir Chaw la
The client 2 provides access to the CCCS and allows parties to perform certain
functions. These
functions include, but are not limited to, initiating collateral deposits to
the account, initiating a
payment transaction request, initiating a deposit to the account, receiving
messages from the
system such as a notification of payment or notification of a deposit
requirement, and obtaining
status from the system. Status may include, but is not limited to, information
such as the
scheduled clearing date, a party's marginable balance, a party's collateral
balance, the current
exchange rates, and the status of the system. Example embodiments of client
features are
illustrated in FIGS 9-29.
As illustrated in FIG 1, in some example embodiments, the client 2 is a
computer connected to
the server through a secured global network 3 such as the internet. This
computer has a dispay or
graphical user interface (GUI) that allows a user to operate the client. In
other example
embodiments, the client 2 may be a browser such as Mozilla Firefox, Google
Chrome, or
Microsoft Internet Explorer installed on a general purpose computer, tablet,
or smartphone.
In some example embodiments, the party may be able to access functionality
associated with
accounts outside of the system. For instance, the party may initiate
withdrawals or deposits,
through the client of the system, to accounts associated with third party
systems 4. As will be
discussed later, this functionality is implemented on the server side 1 of the
CCCS. In this
example embodiment, the server 1 is connected to the third party system
through the secured
global network 3
In other example embodiments, the client 2 may also allow parties to
administer their client 2
and their corresponding accounts. For instance, in the scenario where the
party is a large
organization such as a bank, the bank may wish grant several individuals
access to the
functionality provided by the client 2. In this example embodiment, the client
2 may allow
parties to administer individual user accounts associated with the party's
account. The client 2
may also allow different levels of access to ensure that each user has only
the functionality
required to perform his or her role. For instance, the party's information
technology specialist
may only be able to add or remove parties, whereas a foreign exchange trader
may be able to
initiate payment transactions.
15/38
CA 02826953 2013-09-16
111 69-2j Sam ir Chaw la
In another aspect, the computer implemented method and system has one or more
servers I.
Generally, the server 1 is responsible for processing transactions initiated
from the client 2,
clearing the transactions, fulfilling the transactions, and requesting that
member parties deposit
collateral or margin. Conceptually, the server 1 may be, but is not limited
to, one or more
enterprise-class servers located in a secure location, virtual servers in a
cloud computing
environment, or any other client-server solution.
In example embodiments where the client 2 is a browser, the server 1 may
include a means to
serve web pages. An example of this would be a web server. Examples of web
servers include,
but are not limited to, Apache HTTPD and Microsoft Internet Exchange. These
web servers are
configurable to allow for secured connections between the browser running on
the client 2 and
the server 1.
In an example embodiment, the server 1 comprises a data store 5 for storing
transaction, client,
and system data. In some example embodiments, the data store 5 is managed by a
relational
database manager such as IBM DB2, Oracle, or MySQL. In other example
embodiments, the
data store 5 may be a custom designed data store optimized for transactional
speed and security.
In other example embodiments, the server I may comprise an application
programming interface
(API). Clients 2 can then interact with the server 1 by sending requests to
the server's 1 API. The
server 1 may then acknowledge receipt of these requests, perform the command,
and return a
response to the client 2 that corresponds to a success or failure condition.
From the client's
perspective, this API allows parties to customize or develop their own client
interfaces.
In some example embodiments, when the client 3 issues a request to the server
1, the server 1
will check whether the user is authorized to perform the requested
transaction. For example, in
some embodiments the server 1 determines whether the user is authorized to
perform the
requested transaction by comparing the user information to user data. The
server 1 may then
return an error or notify administrators or both in the instance of an
unauthorized access. In
another example, the server may require that the user log into the system in
order to determine
16/38
CA 02826953 2013-09-16
[169-21 Sarnir Chaw la
the user's access rights.
After the request has been determined to be from an authenticated user, the
server 1 will fulfill
the client's 2 requests. In some example embodiments, the server 1 may respond
to the client 2.
These responses can include, but are not limited to, acknowledgements that the
transaction
request was received, confirmations that the transaction has been completed,
or error messages
indicating that the transaction has failed.
In this example embodiment, client 2 requests can be categorized into three
general categories:
Functions 191, Reporting 192, and Administrative 193. Generally, functions 191
allow clients 2
and system administrators to initiate transactions, accept or reject
transactions, deposit or
withdrawal collateral, and deposit margin requirements. Reporting 192 allows
users to view
upcoming and historical payment, collateral, and margin transactions.
Administrative 193
functionality allows clients to manage their passwords and to set user access
levels for different
client users.
If the user is a system administrator of the CCCS, then the client may have
additional
administrator functionality. In some example embodiments, the Administrator
Functions 3001
allow a system administrator to approve, manually enter, or reject
transactions. The
Administrator Reporting 3002 functions allow CCCS system administrators to
request reports on
the entirely of the system. The administrative 3003 functionality for system
administrators
allows system administrators to manage client accounts and parties, manage
approved assets and
asset classes for collateral, manage approved currencies for transactions,
manage clearing timing,
manage depository settings, and other functionality related to system
administration.
Client Payment Functions
In an example embodiment, client functions that are processed by the server
include "payment
management" 901, "collateral management" 902, and "batch instruction upload"
903. Payment
management functions 901 include "payment order" 1001 and "pending payments"
1002.
17/38
CA 02826953 2013-09-16
1169-21 Sam ir ChaW la
Collateral management 902 functions include "view collateral positions" 1201,
"deposit/withdrawal" 1202, and "pending collateral transactions" 1203.
When the server receives a "payment order" 1001 request from the client 2, the
server 1 initiates
a payment transaction request from the client party's account to a second
member party. FIG 9
shows an example embodiment client payment order interface. The payment order
interface is
used to collect payment order data from the payor party in order to generate a
payment
transaction. The payment order interface may automatically include data it
knows of, for
example the payor party information, in the payment transaction.
The payment transaction comprises payor information, receiver information, the
transaction
amount, the currency of the transaction, a note or memo field, and date
information
corresponding to when the transaction was created, recorded, or last edited.
The payment
transaction data may also include a status field that allows the system to
flag the status of the
transaction. In this example embodiment, the status may identify the
transaction as being
pending, approved, pending approval, cancelled, denied, and fulfilled.
The payment transaction is then recorded in the data store 5. In this example
embodiment, the
data store 5 stores payment transaction information from all payment order
requests from all
parties in a single data table. A skilled person would understand that
alternate configurations can
be used without departing from the scope of this disclosure. For example, in
other example
embodiments each party may have their own data table
In another example embodiment, when the server receives a "pending payments"
1002 request,
the server will retrieve all incoming and outgoing pending payment
transactions from the data
store 5 and present it to the user through the client 2. In some example
embodiments, this data
may be presented for informational purposes only. In this example embodiment,
outgoing
payment transactions can be edited by the payor or the system administrator at
any time before
the clearing window begins. This allows the payor or the system administrator
to adjust the
payment in the case of error, changing market conditions, or any other reason
that would require
the modification of a payment.
18/38
CA 02826953 2013-09-16
1169-21 Saniir Chaw la
In this example embodiment as shown in FIG. 10, the incoming "pending
payments" 1002
request retrieves all pending incoming payments to the party from the data
store 5. These
incoming payments are from other parties of the CCCS. As was discussed above,
these incoming
transactions can be edited or deleted by the payor party at any time prior to
the clearing window.
In other example embodiments, the incoming transactions can be edited or
deleted by the payor
party at any time before the payment is approved by the receiver.
In this example embodiment, the receiving party can either reject or confirm
1003 the incoming
payment. Rejecting the payment changes the status of the payment transaction,
as stored in the
data store 5, to "rejected". Confirming the payment changes the status of the
transaction to
"accepted-pending". Payment transactions with the status of "accepting-
pending" will be
fulfilled during the clearing period. In the embodiment where a payment
transaction comprises a
payor and receiver transaction pair, both the payor and receiver transactions
will be updated in
the data store 5.
In some example embodiments, the "accepted-pending" transactions can also be
used to adjust
the margin balance of both parties. In the case of incoming payments, the CCCS
will increase the
receiving party's available margin for payment transactions. In this example
embodiment, the
value of an approved incoming payment will be reflected in the party's soft
cash margin balance.
This amount can then be used by the party to initiate unrelated payment
transactions to another
party.
In the case of outgoing payments, the CCCS will decrease the payor party's
available margin
balance for payment transactions. In this example embodiment, the value of an
approved
outgoing payment will be reflected in the party's margin balance.
In another example embodiment as shown in FIG 11, the outgoing "pending
payments" 1001
request retrieves all pending outgoing payments from the party to the data
store 5. These
outgoing payments are payments to other parties of the system. As was
discussed above, these
payment transactions can be edited through the client 2 at any time prior to
the clearing window
19/38
CA 02826953 2013-09-16
[169-2] Sarni!. C haw la
or prior to the payment being approved by the receiver. In another example
embodiment, these
transactions may be cancellable. In some example embodiments, when a
transaction is cancelled
it is deleted from the data store 5. In other example embodiments, the status
of the transaction
may be changed to "cancelled".
Furthermore, in the example embodiment where payment transactions comprise a
payor and
receiver pair, both the payor and receiver transactions will be updated. In
this example
embodiment, if a receiver has approved a payment transaction such that the
status of the receiver
transaction is "approved-pending" before the payor party edits the payment
transaction, then the
receiving party may need to re-approve the receiving transaction. That is,
when the payor party
makes the change to the payment transaction, the payor and receiver
transactions will be updated
and its states will be changed to "pending" in the data store 5. The receiving
party will then need
to re-approve or reject the edited transaction.
Client Functions
In another example embodiment, when the server 1 receives a "view collateral
positions" 1201
request from the client 2, the server 1 will retrieve data related to the
party's collateral position
from the data store 5. This data may include the party's hard cash collateral
1204 and approved
collateral 1205 positions. In some example embodiments, a reporting screen
will be presented to
the user through the client 2 that summarizes the client's current collateral
positions, as well as
providing a detailed description of each collateral position entry. In some
example embodiments,
this report may also provide information regarding the remaining margin
balance corresponding
to the collateral.
In an example embodiment, collateral data is stored in the data store 5 in the
same data table as
payment data. Collateral data, however, is is marked as collateral to
distinguish it from payment
data. When the "view collateral" request for hard cash 1204 is being
processed, the server adds
the value of the hard cash collateral. When the "view collateral" request for
assets 1205 is being
processed, the server adds the value of the asset collateral.
20/38
CA 02826953 2013-09-16
69-21 Sanur la
In this example embodiment, the CCCS can also determine a margin value
corresponding to the
value of the collateral. In this example embodiment, as shown in FIGS 12 and
13, the margin
value is the value of the collateral (whether hard cash or assets) converted
to the party's base
currency. In other example embodiments, risk management filters may be applied
to further
reduce the margin value. In yet another example embodiment, the margin balance
may be the
total value of the hard cash and the assets minus any uncleared outgoing
payments made by the
party. This margin balance, as was previously discussed, represents the amount
available for
payment transactions as valued in the party's base currency..
In another example embodiment as shown in FIGS 14 and 15, the party can
initiate a deposit or
withdrawal transaction of hard cash or assets to the CCCS. In this example
embodiment, the
request is sent from the client 2 to the server 1. The server I can
communicate with external
systems through a global secured network 3 to transfer collateral between the
CCCS and external
systems 4. These external systems 4 can include, but are not limited to,
banks, security
depositories, and other financial systems such as clearing houses. In other
example
embodiments, deposits and withdrawals of hard cash can be performed using wire
payments or
other means of transferring cash to the possession of the party. In some
example embodiments
this may include transferring the funds to a third party institution, such as
an agent bank.
In this example embodiment, the client interface as illustrated in FIGS 14 to
16 collects the
requisite data from the party to complete a collateral transaction. In the
example embodiment for
hard cash, this can include the transaction type (deposit or withdrawal), the
amount, the currency,
and the source of the funds. This source can include links to external
financial institutions or wire
transfer identifiers. in the example embodiment for assets, this data can
include the transaction
type (deposit or withdrawal), data identifying the security, the quantity of
the security to be
transferred, and depository information, among other data. This data is then
stored in the data
store 5.
In this example embodiment, depositing hard cash or assets increases the
party's margin balance
for use in payment transactions. In some example embodiments, risk management
filters may be
21/38
CA 02826953 2013-09-16
[169-21 Sam ir Chaw la
applied so that the margin value is less than the actual value of the hard
cash or asset.
Furthermore, withdrawing hard cash or assets reduces the party's available
margin balance for
use in payment transactions. In this example embodiment, withdrawals will be
rejected if the
withdrawal transaction causes the margin balance to drop below a fixed amount.
In this example
embodiment, a party cannot withdraw collateral if withdrawing collateral will
result in a negative
margin balance.
In some example embodiments, when a payment or deposit is made in a currency
other than the
party's base currency a reduction factor, or "haircut", will be applied. This
haircut, which can be
considered a specific risk management filter, accounts for variances and
swings in the global
currency market. In an example embodiment, a 5% reduction to value may be
applied to the
payment or deposit to account for this risk. A skilled person would
understand, however, that the
reduction rate can be set by the CCCS system administrator and that the rate
can be adjusted
based on the volatility of the market.
In another example embodiment, collateral transactions such as deposits or
withdrawals of hard
cash or assets must be approved by a CCCS system administrator before the
deposit or
withdrawal transaction is fulfilled. Prior to these transactions being
approved, the client can
instruct the server to display all collateral transactions that are awaiting
approval.
In the example embodiment where pending collateral transactions must be
approved by the
CCCS or a system administrator of the CCCS, the server 1 may be configured to
retrieve
pending collateral data from the data store 5 and generate a "pending
collateral" report. This
report, when presented to the party through the client 2, shows all collateral
transactions that
have yet to be approved. Example embodiments of these reports are illustrated
in FIG 17 and 18,
where FIG 17 shows a pending collateral report for hard cash and FIG 18 shows
a pending
collateral report for approved collateral.
In the example embodiment shown in FIGS 17 and 18, the party may also cancel
or edit 1701
pending collateral transactions. This allows clients to modify the collateral
transaction at any
time prior to the system administrator approving the collateral transaction.
This can be useful in
22/38
CA 02826953 2013-09-16
[169_21 samir Chawla
circumstances where, for example, a mistake was made.
Client Reporting
In another example embodiment, the client 2 can request reports from the
server 1. Reporting
functions can include, but are not limited to, "margin statements", "cash
clearing statements",
"payment history", and "collateral history". In the "margin statement" and
"cash clearing
statement" reporting functions, the client can request a summary or detailed
version of the
selected report. In the "collateral history" reporting function, the client
can request a historical
report for both hard cash and asset collateral.
In an example embodiment, the server 1 is configured to retrieve data from the
data store 5 and
generate one or more reports related to the party's margin. These reports are
then sent to the
client 2 for presentation to the user. In one example embodiment shown in FIG
19, a summary
report of the party's margin can be generated. The report summarizes the
party's available hard
cash, soft cash (i.e., pending and fulfilled payment orders), and assets. The
total margin collateral
1901 can then be determined by adding the values of the hard cash, soft cash,
and assets, and
subtracting any risk management and currency conversion adjustments.
In some example embodiments the margin summary report may also include the
party's total
margin requirement 1902. In the case where the clearing window has not yet
passed, this number
represents the value of all outgoing payment orders yet to be fulfilled. In
the example
embodiment where the margin summary report shows negative margin balances
after the
clearing window has completed, this value represents the amounts that must be
deposited to the
system to prevent the collateral from being liquidated.
In another example embodiment, the margin summary report may also provide
information
regarding the net margin balance 1903. This value represents the remaining
margin balance
available for outgoing payment transactions. In this example embodiment, the
margin balance is
the total margin collateral minus the margin requirement.
23/38
CA 02826953 2013-09-16
69-2j 4iarnir (*hawk'
In another example embodiment as shown in FIG 20, the server 1 may also be
configured to
retrieve data from the data store 5 and generate a detailed margin statement
for display by the
client 2. In this example embodiment, the server 1 will retrieve and generate
a list of transactions
that affect the party's margin balance. These transactions may include, but
are not limited to,
incoming and outgoing payments. In some example embodiments, the report may
also allow a
party to generate a report for transactions that occurred between a range of
dates.
In another example embodiment as shown in FIG 21 and 22, the server 1 is
configured to retrieve
data from the data store 5 and generate one or more reports related to the
party's cash clearing
transactions for display by the client 2. In this example embodiment, the
server 1 can generate a
summary of all uncleared outgoing and incoming payments for each accepted
currency. In the
case where no transactions are made in an accepted currency that currency is
not displayed in the
report. In this clearing summary, all incoming payments are represented as a
positive value,
whereas all outgoing payments are represented as a negative value. In some
example
embodiments where the party must accept the incoming transaction, this
incoming value will not
be included in the clearing balance until the transaction has been approved by
the party.
In another example embodiment as shown in FIG 22, the server 1 is configured
to retrieve data
from the data store 5 and generate a detailed report of the party's cash
clearing transactions for
display by the client 2. In this example embodiment, the server 1 will
retrieve details for each of
the incoming and outgoing transactions for a selected currency and a given
date range. The date
and time of the transaction and a memo describing the transaction may also be
retrieved from the
data store. The credit or debit value of the transaction is also retrieved, as
is the margin balance
at the time of the transaction. The server 1 then orgranizes this data for
presentation through the
client 2. This report can be useful for accounting, tracking, and
administrative purposes.
In another example embodiment as shown in FIG 23, the server 1 is configured
to retrieve data
from the data store 5 and generate a report of the party's payment history for
display by the client
2. This report allows a party to search through their incoming and outgoing
payment
transactions. In this example embodiment, the party can search for payment
transactions based
24/38
CA 02826953 2013-09-16
[I 692jSam ir (haw la
on a date range, an account number, another party in the system, a currency,
by direction, and
whether the transaction is a hard cash transaction. In some example
embodiments, incoming
transactions are recorded as "rec" (i.e., received) transactions, and outgoing
transactions are
recorded as "pay" transactions.
The server 1 will then retrieve all payment transactions from the data store 5
that meet the search
criteria. In the example embodiment where payment transactions are made in
currencies other
than the base currency, the margin balance will be adjusted based on the
prevailing exchange rate
for that currency. Furthermore, the margin balance displayed in the report may
also be adjusted
by the various risk management filters.
in another example embodiment as shown in FIGS 24 and 25, the server 1 is
configured to
retrieve data from the data store 5 and generate a report of the party's
collateral history for
display through the client 2. This can include reports on the party's hard
cash and asset collateral
positions.
In some example embodiments a party may search for collateral deposit and
withdrawal
transactions over a date range. Furthermore, depending on the type of
collateral, additional
search fields may be provided. In the case of hard cash collateral transaction
reporting as shown
in FIG 24, the party may also search by the type of currency. In the case of
asset collateral
transaction reporting as shown in FIG 25, the party may search on the security
identifier (ISIN),
the depository depot, and whether the transaction was a deposit or a
withdrawal.
Client Management Tools
In some example embodiments the member party may be able to manage staff and
account logins
for users associated with the party. In the example embodiments shown in FIGS
26 to 29, parties
can add, edit, and delete users. Parties may also be able to set a user's
access level, which will
determine the functionality available to the user through the client 2. In
these example
embodiments, the server I may validate the data input through the client 2 to
ensure that data, for
25/38
CA 02826953 2013-09-16
[169-21 Samir Chawla
example, is formatted correctly. The server 1 then stores the data in the data
store 5.
In this example embodiment as shown in FIG 27, the party can retrieve user
data. In this example
embodiment, the server 1 is configured to retrieve data from the data store 5
and present it
through the client 2. The party may filter the data based on the username,
actual name, phone
number, or email, among other things. In this example embodiment the party may
also update the
user's credentials. Any updates are stored, by the server 1, in the data store
5.
In another example embodiment as shown in FIG 28, the party can update,
suspend, or delete a
specific user. The party may also reset the user's password in the event that
the password is lost
or otherwise compromised. The party can also add a new user as shown in FIG.
29. In each of
these cases the server 1 is configured to update the data store 5 accordingly.
CCCS System Admin Interface
In the example embodiment where the user is a CCCS system administrator, the
user may be
presented with the administrative functionality described below. Depending on
the
administrator's authorization level, some or all of the functions described
below may be
available.
In an example embodiment, the CCCS system administrator's interface can be
divided into three
main sections: "functions" 3001, "reporting" 3002, and "administration" 3003.
The "functions"
section allow the CCCS system administrator to perform functions on the
transactions such as
removing, editing, approving, or rejecting transactions. The "reporting"
section allows the CCCS
system administrator to generate reports related to the CCCS such as pending
or historical
payment, collateral, or clearing transactions. The "administration" section
allows the CCCS
system administrator to administer the CCCS. This can include, but is not
limited to, updating
exchange rates, collateral prices, interest rates, scheduling clearing
windows, updating depository
information, clearing member or party information, and similar administrative
tasks.
26/38
CA 02826953 2013-09-16
69-21 Sam ir Chaw la
In some example embodiments, client transactions such as payments and
collateral transactions
may need to be confirmed prior to the system accepting the transaction. In
some example
embodiments, the system may automatically review and confirm these
transactions based on risk
management principles. In other example embodiments, a CCCS system
administrator may need
to review and confirm the payment and collateral transactions. In other
example embodiments
the CCCS system administrator may be able to manually enter collateral and
payment
transactions. This functionality is useful in scenarios where a network outage
prevents parties
from initiating transactions.
In an example embodiment as shown in FIG 30 , a CCCS system administrator may
review and
confirm collateral deposits and withdrawals of hard cash and assets. In this
example
embodiment, after the party has initiated a transaction through the collateral
deposit/withdrawal
interface (e.g., FIGS 14 to 16), the collateral transaction is stored in the
data store 5 as "pending
review". This indicates that the transaction should be reviewed before it can
be fulfilled. It
should be noted that any transaction that is denied, not approved, or is not
confirmed will not be
committed during the clearing window.
In some example embodiments, the CCCS will automatically review and confirm
pending
collateral transactions that meet the system's risk management criteria. Any
transactions that fail
to meet the system's risk management criteria are rejected. In some example
embodiments, the
party may be notified of the rejection.
In the example embodiment shown in FIG 30, one or more CCCS system
administrators may
review and confirm the pending collateral transactions. In this example
embodiment, the server 1
retrieves data from the data store 5. In this example embodiment this data is
a list 3004 of all
pending collateral deposits, both hard cash and assets. This list is then
provided to the CCCS
system administrator, through the client 1, for review. The CCCS system
administrator may filter
this list based on the currency and member identifier. The CCCS system
administrator then
reviews the transaction to determine whether it meets the system's risk
management criteria.
Transactions that meet the risk management criteria are confirmed,whereas
transactions that fail
the risk management criteria are rejected. The change is then recorded in the
data store 5. In this
27/38
CA 02826953 2013-09-16
l 69-21 Saniir Chaw la
example embodiment the existing transaction record in the data store 5 is
updated to reflect
whether the transaction was accepted or rejected.
In another example embodiment as shown in FIG 31 to 33, the system may allow a
CCCS
system administrator to manually enter collateral transactions of both hard
cash and assets on
behalf of a party. This allows collateral deposit or withdrawal transactions
to be made even in the
event of a network outage. In this example embodiment, a party contacts a CCCS
system
administrator and instructs the CCCS administrator to manually enter a
collateral transaction.
The administrator will then enter the transaction using the instructions
provided by the party. In
the case of hard cash, the CCCS system administrator will be required to enter
the type of the
transaction and the amount and type of currency into a client interface such
as the one shown in
FIG 31. In the case of of an asset, the system administrator will be required
to enter information
related to the asset into a client interface such as the one shown in FIG. 32
and 33. This may
include, but is not limited to, the asset type, the amount, the depository,
and the ISIN number.
This information is then stored in the data store 5 as a collateral
transaction, in the same location
collateral transactions would typically be stored.
In some example embodiments, when a CCCS system administrator manually enters
a collateral
transaction into the system, the collateral transaction is automatically
confirmed. That is, the
system administrator can apply the risk management filters as the transaction
is being entered
into the system. In another example embodiment where the system automatically
handles risk
management, risk management filters will be applied to the transaction before
the transaction is
confirmed.
In another example embodiment as shown in FIG 34, the system may allow for
payment
transactions to be entered manually by a CCCS system administrator for similar
reasons to the
manual collateral entry functionality described above. In this example
embodiment, the party
contacts a CCCS system administrator and instructs the administrator to
manually enter a
payment transaction. This communication can include emails from a verifiable
email account,
faxes, etc. In another example embodiment, the CCCS administrator can verify
that the
communication originated from a party. For example, a CCCS administrator may
require a
28/38
CA 02826953 2013-09-16
[1 69-2] Sainir Chaw la
passcode or phrase before accepting the instruction from the party.
The administrator will then enter the transaction using the information
provided by the party into
the interface as shown in FIG 34. This information is then sent to the server
1 where this
transaction is stored in the data store 5. In some example embodiments, the
risk management
filters will be applied as the transaction is entered into the system, similar
to the risk analysis
filters applied during a manual collateral transaction. In other example
embodiments, the risk
management filters will be applied to the transaction before the transaction
can be confirmed.
In another example embodiment as shown in FIGS 35 to 43, the server 1 is
configured to retrieve
data from the data store 5 and generate reports for the CCCS system
administrator to review.
These reports may include information related to the collateral, margin, and
payment transactions
for one or all of the member parties.
In this example embodiment, the server 1 is configured to retrieve data from
the data store 5 and
generate margin statements for display through the client 2. These margin
statements provide
information regarding the margin positions of each party. In this example
embodiment, a margin
summary and detailed margin summary report can be generated.
In an example embodiment as shown in FIG 35, the server 1 is configured to
retrieve data from
the data store 5 and generate a margin summary report for the CCCS system
administrator to
review. This report displays each party's total margin collateral, margin
requirement, and margin
balance. This allows a system administrator to quickly identify whether a
party has sufficient
collateral in the system to cover its payment obligations should the party
default. This
information can be used by the system administrator to, for example, determine
the risk the party
poses to the system.
In another example embodiment as shown in FIG 36, a detailed margin summary
for each party
can be generated by the system for review by the CCCS system admin. This
report allows the
system administrator to review all transactions that affected a specific
party's margin over a
given date range. This report includes information related to whether the
transaction was a debit,
29/38
CA 02826953 2013-09-16
I 169-2i Sam ir CIlaw la
a credit, and the party's net margin balance after the transaction was
confirmed. This report may
also show a change in margin for a party in the party's base currency, where a
change in margin
can be, without limitation, margin updates, collateral deposit/withdrawals,
incoming/outgoing
guaranteed payments, and clearing.
In another example embodiment as shown in FIGS 37 and 38, the server 1 is
configured retrieve
data from the data store 5 and generate clearing reports for display through
the client 2. These
reports allow a CCCS system administrator to review the cleared transactions
for each currency
from the last clearing period. Additional clearing reports may provide
information regarding
clearing transactions for all parties over a date range. These reports can
help the system
administrator monitor and troubleshoot the system and to ensure that all
transactions are clearing
to a zero (0) net amount for all parties.
In an example embodiment as shown in FIG 37, the CCCS is configured to
generate a cash
clearing summary. This report summarizes all cash clearing transactions from
the previous
clearing period in a specific currency for all parties. This provides a quick
way for a CCCS
system administrator to review the cleared transactions and ensure that the
net clearing balance
for all parties for that particular currency is zero (0). If the net clearing
value is not zero (0) then
an error has occurred and the system administrator can investigate the issue.
In another example embodiment as shown in FIG 38, the system is also
configured to generate a
detailed cash clearing summary. This report allows CCCS system administrators
to review all
cleared transactions over a date range for a specified party. Information such
as the date and time
the transaction cleared, the currency of the transaction, the system payment
id, the other party to
the transaction, the debited/credited amount, and the remaining margin balance
for that party can
be included in the report. This information may be useful when troubleshooting
the system or
determining the risk to the system. This information may also be useful for
research, auditing,
reconciliation, accounting, and calculating metrics for future improvements to
the system.
In another example embodiment as shown in FIG 39, the server 1 is configured
to retrieve data
from the data store 5 and generate a detailed payment history report for
display via the client 2.
30/38
CA 02826953 2013-09-16
[169-21 Sam ir C haw la
In an example embodiment, the CCCS system administrator can search for payment
transactions
using one or more criteria. These criteria can include, but are not limited
to, a date range, the
payment ID, the payor party, the receiving party, the currency, or whether the
transaction was
hard cash or soft cash. In this example embodiment, the generated report will
contain the data
provided above, as well as the relevant transaction amounts, the currency, and
the effect on the
party's margin balance by displaying a transaction's margin value.
In another example embodiment as shown in FIGS 40 and 41, the server 1 is
configured to
retrieve data from the data store 5 and generate reports for each party's
collateral transactions for
display via the client 2. These reports are similar to the collateral history
reports that parties can
generate, as was previously discussed. In other example embodiments, the CCCS
system
administrator report may generate a report that provides data for all
collateral transactions for all
parties at the same time.
In another example embodiment as shown in FIGS 42 and 43, the server 1 is
configured to
retrieve data from the data store 5 and generate reports for the total hard
cash and asset collateral
currently held by the system for display via the client 2. This allows CCCS
system administrators
to quickly determine the total collateral held by the CCCS for each party.
This can be used to
determine the overall risk and stability of the system. In the case of hard
cash, the system will
display the total amount of hard cash, for each party, held as collateral for
each currency as
shown in FIG 42. In the case of assets, the system will display the total
assets held as collateral
by the system, as shown in FIG 43.
CCCS System Administration
In another example embodiment as shown in FIGS 44-48, the system is configured
to allow
CCCS system administrators to administer aspects of the CCCS. These can
include adding,
editing, and removing each of the following from the CCCS: parties, users,
currencies,
depositories, and acceptable assets. The administrative functions may also
include the ability to
schedule clearing windows for the CCCS.
31/38
CA 02826953 2013-09-16
1169-21 Samir Chawla
In an example embodiment shown in FIG 44, the CCCS is configured to allow a
system
administrator to schedule one or more clearing windows. As was previously
discussed, the
clearing windows commit any uncommitted payment transactions. Parties with
positive or
negative clearing balances when the clearing process has initiated will be
notified. Those parties
with positive payment balances may elect to either withdraw the cash or add
the payment amount
to their available collateral. Those parties with a negative balance will be
required to deposit an
amount equal to the negative balance. Failure to deposit the amount within a
given time frame
will result in liquidation of the party's collateral so that the party's
negative balances in each
currency can be covered by the CCCS.
In this example embodiment, when a clearing process of a specified window is
initiated the
server 1 retrieves all uncommitted payment transactions from the data store 5.
In some example
embodiments, these may be those payment transactions that are in the
"accepting-pending" or
"pending" state. The system 1 then generates, for each party, a clearing
balance in every
currency. In some example embodiments, the system 1 offsets all payment and
receipt
transactions for each party. For example, if a party has a payment transaction
of $1,000 USD and
a receipt transaction of $500 USD, then the net clearing balance is negative
$500 USD. Parties
are then notified through the client 2 if they have a positive or negative
clearing balance.
In an example embodiment, a system administrator sets the clearing window by
entering the next
clearing window's date and time information. This information will be
presented to the party
when they use the CCCS. In some example embodiments, the CCCS may allow the
CCCS
system administrator to set the clearing window down to the second. In another
example
embodiment, a recurring series of payment windows can be scheduled in the
system. For
example, in another implementation a calendar may be provided that allows a
system
administrator to graphically input recurring clearing dates. In some example
embodiments a
countdown timer may also be provided. This countdown timer notifies the system
administrator
of the time remaining before the next clearing window.
In this example embodiment, the CCCS system administrator enters the clearing
window data
32/38
CA 02826953 2013-09-16
1169-21 Saniir Chaw la
through the client 2. The request is then sent to the server 1 for processing.
In this example
embodiment the server 1 may validate the data from the client 2 to ensure that
correct values are
being entered. Once the server 1 has validated the data, the data is then
stored in the data store 5.
The CCCS will then begin the clearing process on the specified date and time.
In another example embodiment, the CCCS system administrator may be able to
initiate the
clearing process by clicking on a button shown through the client 2. This
provides a convenient
mechanism for the CCCS system administrator to initiate the clearing process
immediately.
In another example embodiment as shown in FIG. 45, a CCCS system administrator
may add,
edit, or remove parties to or from the system. Parties, also known as members,
of the system can
include, but are not limited to, individuals, corporations, banks, non-profit
organizations,
countries, trading houses, clearing houses, and investment banks.
In this example embodiment as shown in FIG 45, a CCCS system administrator can
add a
member and edit a member's profile where necessary through the client 2. This
information may
include, but is not limited to, address and contact information, nation, role
in the system (e.g.,
administrator, manager, trader), and name. In this example embodiment, the
information entered
at the client 2 may be validated at the server I. This can be used, for
example, to verify that email
addresses or phone numbers are properly formatted. The data is then stored in
the data store 5
after the data has been validated.
In some example embodiments, new members must be approved before the member is
permitted
to use the system. For example, in some circumstances it may be prudent to vet
the member to
ensure that the party does not introduce volatility into the system. In these
circumstances, the
member profile may be stored in the data store 5 as a "pending" record until
the various checks
have been completed. These checks can include, but are not limited to,
background checks, credit
checks, or identity checks. Furthermore, these checks may be performed by the
CCCS or by an
external third party. For instance, in an example embodiment the CCCS may be
in
communication via a global secured network 3 with a third-party validation
system.
33/38
CA 02826953 2013-09-16
El 69-21 Sam ir Chaw la
In another example embodiment, the server 1 is configured to retrieve from and
the data store 5
and generate a list of all pending parties of the CCCS. In another example
embodiments, the
CCCS system administrator may edit the pending party's status from pending to
member through
the member management screen as displayed through the client 2, as shown in
FIG. 45. In yet
another example embodiment, the system administrator may also suspend or
remove clearing
members or their users from the CCCS.
In another example embodiment as shown in FIG. 46, a CCCS system administrator
can view,
edit, and add an approved asset. An approved asset is one that can be used as
collateral in the
CCCS. In principle, any non-cash asset can be used as collateral. As was
discussed earlier,
however, stable and liquid assets are generally preferred over illiquid
assets. Examples of liquid
and stable assets include, but are not limited to, corporate and national
bonds, government debt,
and precious metals.
In another example embodiment, the CCCS may allow assets that are highly rated
by a third
party rating agency to be used as collateral. For instance, in some example
embodiments, the
CCCS may use ratings lists from agencies such as Moodys or Standard & Poors to
determine a
list of approved assets.
In this example embodiment as shown in FIG 46, the asset's unique identifier
(ISIN), the name
of the security, the maturity date, the currency, and the price can all be
entered and edited by the
CCCS system administrator through the client 2. In another example embodiment,
the key asset
data such as the price or maturity date can be obtained from a trusted and
secured data source
that is connected to the server 1 through the global secure network 3. In some
example
embodiments this data may be validated by the server 1. This validation can be
used to ensure
that the collected data is formatted correctly. Once the data has been
validated, the server 1 then
stores the data in the data store 5.
In another example embodiment as shown in FIG 46, the server 1 is configured
to retrieve from
the data store 5 and generate a list of approved assets. The CCCS system
administrator can
review the retrieved data for correctness, edit the data, or delete the
approved asset from the
34/38
CA 02826953 2013-09-16
1169-21 Sam ir Chaw ia
system. When an approved asset is updated or deleted the server 1 updates the
data store 5
accordingly.
Similar to the asset settings above, in another example embodiment as shown in
FIG. 47 a CCCS
system administrator can to view, edit, delete, and add a currency approved
for use in the CCCS.
In principle, any currency could be used in the system. In use, however, it is
expected that only
the world's most commonly traded currencies would be used in this system.
These currencies can
include, but are not limited to, the American, Canadian, and Australian
Dollar, the Euro, the
Japanese Yen, the Chinese Yuan, the British Pound, and the Swiss Franc. In
some example
embodiments the system administrator can manually update the foreign exchange
rate relative to
a base currency. In this example embodiment, the US dollar is set as the
system base currency
and all other currencies have an exchange rate relative to the US dollar. In
other example
embodiments the server 1 can obtain key currency data, such as exchange rate,
automatically
from a trusted and secured data source connected to the server 1 through the
global secured
network 3.
Similar to the currency settings above, in another example embodiment a CCCS
system
administrator may view, edit, delete, and add an interest rate. In this
example embodiment the
interest rates is applied to any positive or negative margin balances. In some
example
embodiments, the interest rate is set by the CCCS system administrator to
account for regulatory,
risk, and legal restrictions and can be any arbitrary number, within legal
limits. In other example
embodiments, the interest rate can be agreed upon by members of the CCCS.
In yet another example embodiment, the interest rates can also be bilaterally
agreed upon by
payor and receiver parties. In this example embodiment, the bilaterally agreed
upon interest rate
is stored in the data store. This interest rate is then applied to the payment
transaction of the
payor party and the receipt transaction of the receiver party such that the
interest amounts
applied net to zero (0). In another example embodiment, the CCCS may levy a
fee for the
interest calculation and collection and apply it to the payor's balance, the
receiver's balance, or
both.
35/38
CA 02826953 2013-09-16
[1 69-21 Sam ir Cl ark la
In other example embodiments, the interest rate is based on a commonly
accepted interest rate
such as the US or Canadian inter-bank loan rate. In the example embodiments
provided above,
the CCCS system administrator may manually enter the interest rate through the
client 2. The
server 1 may then validate the data entered through the client 2. Once
validated, the interest rate
is then stored in the data store 5. In another example embodiment, the
interest rate is obtained
automatically from a trusted and secured data store connected to the server 1
through the global
secured network 3.
In another example embodiment as shown in FIG 48, a CCCS system administrator
can add,
delete, and update depository information. As was previously discussed, a
depository holds and
transfers securities on behalf of parties and institutions. In this example
embodiment, the system
administrator can manually enter the information of approved depositories
through the client 2.
This data may be validated by the server 1 to ensure that the data, for
example, complies with
formatting rules. The server 1 then stores the data in the data store 5. In
other example
embodiments, the depository information may be obtained from a trusted and
secured data
source connected to the server 1 through a global secured network 3.
In this example embodiment, only depositories approved by the system can be
used to hold or
transfer assets as collateral on behalf of the system. In another example
embodiment, any
attempts by parties to deposit or transfer assets using an unapproved
depository will not be
recognized as collateral by the system.
The present system and method may be practiced in various embodiments. A
suitably configured
computer device, and associated communications networks, devices, software and
firmware may
provide a platform for enabling one or more embodiments as described above. By
way of
example, FIG 49 shows a generic computer device 500 that may include a central
processing unit
(CPU) 502 connected to a storage unit 504 and to a random access memory 506.
The CPU 502
may process an operating system, application program, and data. The operating
system,
application program, and data may be stored in storage unit 504 and loaded
into memory 506, as
may be required. Computer device 500 may further include a graphics processing
unit (GPU)
522 which is operatively connected to CPU 502 and to memory 506 to offload
intensive image
36/38
CA 02826953 2013-09-16
1169-21 Sarnir Chaw la
processing calculations from CPU 502 and run the calculations in parallel with
CPU 502. An
operator 507 may interact with the computer device 500 using a video display
508 connected by
a video interface 505, and various input/output devices such as a keyboard
510, mouse 512, and
disc drive or solid state drive 514 connected by an I/O interface 509. In
known manner, the
mouse 512 may be configured to control movement of a cursor in the video
display 508, and to
operate various GUI controls appearing in the video display 508 with a mouse
button. The disk
drive or solid state drive 514 may be configured to accept computer readable
media 516. The
computer device 500 may form part of a network via a network interface 511,
allowing the
computer device 500 to communicate with other suitably configured data
processing systems
(not shown).
In further aspects, the disclosure provides systems, devices, methods, and
computer
programming products, including non-transient machine-readable instruction
sets, for use in
implementing such methods and enabling the functionality described previously.
Although the disclosure has been described and illustrated in exemplary forms
with a certain
degree of particularity, it is noted that the description and illustrations
have been made by way of
example only. Numerous changes in the details of construction and combination
and
arrangement of parts and steps may be made. Accordingly, such changes are
intended to be
included in the disclosure, the scope of which is defined by the claims.
Except to the extent explicitly stated or inherent within the processes
described, including any
optional steps or component thereof, no required order, sequence, or
combination is intended or
implied. As will be understood by those skilled in the relevant arts, with
respect to both processes
and any systems, devices, etc., described herein, a wide range of variations
is possible, and even
advantageous, in various circumstances, without departing from the scope of
the disclosure,
which is to be limited only by the claims.
It is obvious that the foregoing embodiments of the invention are examples and
can be varied in
many ways. Such present or future variations are not to be regarded as a
departure from the
scope of the invention, and all such modifications as would be obvious to one
skilled in the art
37/38
CA 02826953 2013-09-16
[169-2] Sam ir Chavvia
are intended to be included within the scope of the following claims.
38/38
