CA 02435909 2003-07-24
WO 02/059847 PCT/CA02/00107
ONLINE PAYMENT TRANSFER AND IDENTITY MANAGEMENT
SYSTEM AND METHOD
Field of Invention
The present invention relates to a system and method for online monetary
transfers. In
particular, the invention relates to an online payment and identity management
system and
method for delivering payments from a financial institution over a global
computer network.
Background of the Invention
In the recent past a number of non-financial institution technology firms have
bypassed banks by launching independent, Internet-based person-to-person (P2P)
payment
mechanisms. Most such services require consumers to register and debit a
credit card or banlc
account before sending a payment. Recipients of payments receive email
notifications with a
specially coded link to register and authenticate before receiving several
payment options,
such as depositing into a bank or credit card account.
I~ue to consumer demand and the "viral" nature of these mechanisms (by
compelling
recipients to register in order to collect payments), uptake has been
significant. Consumers
want a convenient Internet mechanism to pay for online purchases and to
replace "one-off "
checks and cash payments, both domestically and internationally. For example,
consider the
millions of consumers who regularly wire money to family members that live
abroad. For
traditional financial institutions, the advent of P2P payments represents both
a threat and an
opportunity. Banks risk losing customer relationships to third-parties that
will quicl~ly try to
expand their offerings into other traditional banking functions, competing
with online
checking accounts, business accounts and merchant payment services.
With non-bank start-ups acquiring P2P market share, banlcs risk never
recouping their
massive investments in online infrastructure. Once a non-bank has entered the
P2P payment
transfer market, there is an opportunity to go beyond free P2P payments and
offer consumers
a full range of financial services, such as interest bearing sweep accounts,
low-fee mutual
funds and business accounts equipped to accept merchant payment.
Unlike other pure-play Internet banks, which have spent millions of dollaxs on
advertising to promote their brands, non-bank P2P payment transfer firms have
employed
P2P payments to drive the initial adoption of their service and, in the
process, have
-1-
CA 02435909 2003-07-24
WO 02/059847 PCT/CA02/00107
significantly reduced the average customer acquisition cost. Once a non-bank
P2P provider
makes inroads into a bank's customer relationships, it becomes easier to gain
further ground.
As a result, financial institutions face the danger of disintermediation by
aggressive non-bank
up-starts. Demand for such services has been so high that some banks are
offering P2P
payments to position themselves against third-parties and to acquire online
customers. They
include portals designed to aggressively capture new clients.
Competition with on-line banking services is arising from other payment
providers in
other forms as well, such as auction payments, online gift certificates,
event, micropayments
and stored-value, payment processing, global payments and specialty consumer
payments.
Most of these P2P payment services are positioned to operate outside of the
traditional
financial system. As such, consumers are forced to use third-party P2P
services requiring
personal financial information. This raises a number of privacy and security
concerns.
Moreover, poor performance by a non-bank third party (which is typically not
regulated to
the extent that banks and other financial institutions are) can undermine
consumers'
perception of the reliability of on-line financial service transactions
generally.
Furthermore, consumers axe suffering from password fatigue, and many are
looking to
simplify the manner in which day to day transactions and activities are
conducted. Consmners
look to their banks, which have already established the requisite credibility
in financial
dealings, to offer additional services from their core banking relationship.
Summary of the Invention
The present invention provides a person-to-person (P2P) payment platform and
identity management system which facilitates online banking by allowing bank
customers to
send and receive money in real-time, with no special registration requirement
outside of the
customers' existing banking relationship, and under the security, brand and
control of their
own respective banks.
The invention provides an invisible application service provider in the form
of a
central clearing facility (CCF) which coordinates and manages payments for
customers,
nationally and internationally, through partner financial institutions.
According to the
invention, customers send payments from witlun their online banking accounts,
under their
bank's existing authentication and security. Thus, customers can transfer
money directly from
an existing online banking offering without setting up separate accounts
profiles and
-2-
CA 02435909 2003-07-24
WO 02/059847 PCT/CA02/00107
passwords. Customers trust banks to move money more securely than non-bank
third-parties,
and as such will more readily respond to a payment solution offered under
their bank's
security provisions.
The CCF is invisible, and effectively operates under the bank's brand so the
bank
retains the entire customer goodwill and developed brand recognition. In
addition, each
payment, in particular those delivered by e-mail, prompts recipients who don't
banlc online to
sign up for their bank's Internet-based services to deposit payments directly
into their
accounts, thus increasing the bank's goodwill and facilitating the cross-
selling of financial
services. The e-mail payment option is a high-demand functionality that
provides
recognizable customer value and replaces customer inconvenience with real-time
transactions
and convenience to create more positive customer experiences. In addition to
being amble to
initiate and receive payments using online banking services accessible via the
web,
customers can also utilize automated teller machines (ATMs), wireless
networks, telephone,
and any other access means provided by the financial institution to its
customers.
In the preferred embodiment, to make a P2P payment the customer:
1. Accesses the online banking service;
2. Selects a recipient from a list of past payees or enters new recipient
information to create a
new payee;
3. Specifies a payment amount, the account from which to draw the funds, and
optionally an
expiry date and a personalized message to the recipient; and
4. Confirms the transaction to authorize the bank to draw the funds, following
which
notification is sent to the recipient advising of payment with referrals to
various methods of
collection; and
5. Receives a confirmation message when the recipient accepts the payment.
The recipient may:
1. "Web enable" an existing account or open online banking services;
2. Deposit the payment into any banlc account;
-3-
CA 02435909 2003-07-24
WO 02/059847 PCT/CA02/00107
3. Deposit the funds into a credit card account;
4. Request delivery of a paper check; or
5. Receive funds directly if the online banking service is an ATM.
The invention thus renders P2P payments under the control of the bank and
eliminates
the need for the bank's customers to use a third-party service. The bank
controls all front-end
consumer touchpoints including end-user communications. The banlc also has the
ability to
control how P2P payment capability drives new revenue sources, cuts costs and
increases
marlcet share, to create new revenue streams, reduce acquisition costs of new
customers,
increase marketing and cross-sell opportunities and reduce dependence on less
efficient
delivery channels.
The invention supports different frequencies of payment and multiple
currencies, and
can be deployed on all bank delivery channels, including wireless services.
All of these
services can generate new revenue opportunities for online business,
complemented with
tools that enable the bank to track and control usage.
The CCF's infrastructure is secure and scalable, able to employ the latest
encryption
technologies and security measures to deliver sound and secure transactions.
The invention
allows the bank to determine and configure a wide array of security
parameters, such as
maximum transaction limits, to suit each particular institution's rislc
tolerances. If payments
are undeliverable or unretrieved, the sender can have the funds re-credited to
their bank
account or re-send the payment. A simple, yet robust data interface enables
the bank's
Internet service to connect quickly and securely to the CCF central facility
with minimal
diversion of its technical resources.
The invention thus builds on the bank's relationship with its client, by
adding new
functionality to block out third-party online financial service providers and
strengthen the
existing relationship. Moreover, the invention forecloses the need for
account, ID, password
and other inconvenient administrative requirements that third-party financial
services
providers must ask of consumers. The bank has the opportunity to leverage
existing security
and Internet payment infrastructures, replace consumer inconvenience with
convenience and
provide a facility for real-time email payments between customers of the same
or different
financial institutions.
-4-
CA 02435909 2003-07-24
WO 02/059847 PCT/CA02/00107
The CCF can coordinate payment transactions between customers banking at both
partner and non-partner financial institutions. It handles and stores all of
the payment
relationships among customers and manages the authentication and approval of
fund
disbursements to payment recipients.
Brief Description of the Drawings
In drawings which illustrate by way of example only a preferred embodiment of
the
invention,
Figure 1 is a block diagram illustrating a real-time.cleaxing network for P2P
payments
according to the invention,
Figure 2 is a bloclc diagram illustrating the payor-payee relationship in the
network of
Figure 1,
Figure 3 is a block diagram illustrating user and data interfaces according to
the
invention,
Figures 4a and 4b are block diagrams illustrating an online P2P payment
transaction
where both payer and payee bank at a partner financial institution,
Figure Sa and Sb are block diagrams illustrating an offline P2P payment
transaction
where the payee does not bank at a partner financial institution,
Figure 6 is a graph illustrating account netting at a partner financial
institution,
Figure 7 is a flow diagram illustrating the navigation path for an ovine P2P
payment
transaction where both payer and payee bank at a partner financial
institution,
Figure 8 is a block diagram illustrating an identity management system
according to
the invention,
Figures 9a and 9b are diagrammatic illustrations of a sequence of user
interfaces for a
payer sending a payment,
Figure 10 is a diagrammatic illustration of a sample of a message to a payee,
Figure 11 is a diagrammatic illustration of user interfaces for payee identity
authentication,
-5-
CA 02435909 2003-07-24
WO 02/059847 PCT/CA02/00107
Figure 12 is a diagrammatic illustration of a user interface for a payee
retrieving a
payment,
Figure 13 is a table illustrating user notifications generated according to
the invention,
Figure 14 is a table illustrating a request/response message set in the
interaction
between the CCF and a partner financial institution,
Figure 15 is a table illustrating a sample message sets,
Figure 16 is a bloclc diagram illustrating a preferred security system for the
CCF, and
Figure 17 is a block diagram illustrating the relationship between logical
service items
in the system of the invention.
Figure 18 is a block diagram illustrating an online P2P payment where the
payee
receives payment at an ATM.
Figure 19 is a block diagram illustrating an online P2P payment between
businesses.
Figure 20 is a block diagram illustrating an online P2P payment between a
customer
and a retailer.
Figure 21 is a block diagram illustrating a network for P2P payments between a
payor
and a payee in different jurisdictions according to the invention.
Detailed Description of the Invention
The system and method of the invention enables customers of a financial
institution
having access to banking services over a global computer network such as the
Internet to
initiate electronic payments conveniently and securely from their financial
institution's self
service delivery channels (Online banking service, ATM, Wireless, Telephone
Banking) or
the financial institution's branch. The invention provides financial
institutions with an easy-
to-integrate mechausm to facilitate and manage person-to-person (P2P)
payments, leveraging
existing fund transfer mechanisms that reside in the middleware of a financial
institution's
banking service - the component that allows customers to move money between
their own
accounts - thereby avoiding significant back-end development. The invention
extends an
institution's existing infrastructure to facilitate funds transfers in and out
of consolidation
trust accounts established at partner financial institutions in each supported
currency.
-6-
CA 02435909 2003-07-24
WO 02/059847 PCT/CA02/00107
To process P2P payments, the invention helps partner institutions feed
transaction
interfaces with the appropriate account numbers, parameters and
authorizations. "Netting"
processes balance the positions of consolidation trust accounts across all
partner financial
institutions. As a result, a private, real-time clearing network is created
among partner
institutions to settle electronic payments initiated and caught by their
customers. This allows
financial institutions to maintain control over their user interface by
communicating with a
central clearing facility (CCF) through industry-standard messaging adaptors.
The CCF
manages the status and accounting mechanisms to ensure that users at each end
of a payment
transfer are validated and notified throughout each step of the transaction.
The GCF featuxes a
secure, open front-end to allow users that do not currently bank at partner
institutions to
"catch" payments using offline mechanisms that can reach and credit most
accounts. If
payees do not wish to receive payment electronically, they can request a check
mailed to their
address or, if receiving payment at an automated teller machine (ATM), they
can obtain the
funds directly.
The CCF is based on an application service provider model that uses industry-
standard interfaces to integrate with partner financial institutions' existing
systems. The
invention acts as a common platform among banks, interacting with each to
support the
efficient exchange of P2P payments. The net result is one of ease and
efficiency: each
financial institution establishes a one-to-one relationslup with the CCF,
eliminating the
prospect of integrating disparate systems.
Figure 1 illustrates an Application Service Provider Model which allows
financial
institutions to rapidly deploy P2P payments on their appropriate delivery
channel (Online
Banking, ATM, Wireless, etc.) To maximize security and to minimize the risk of
fraud,
payments are always initiated from within the authenticated layer of a partner
financial
institution's delivery channel. As a result, each payment that enters the
system for delivery
originates from a trusted source. As shown in Figure 2, payees can receive
their funds
through the originating institution (Payee #1) or at another affiliated
partner (Payee #2).
Alternatively, customers banking at unaffiliated financial institutions (Payee
#3) can request
payment through offline disbursement mechanisms offered at a secure Web site
powered by
the CCF. Partner financial institutions thus become a secure, real-time
clearing network for
P2P payments.
_7
CA 02435909 2003-07-24
WO 02/059847 PCT/CA02/00107
The architecture of the invention, illustrated in Figure 3, consists of data
and user
interfaces that facilitate the movement of money between customers. Behind the
scenes, a
secure CCF Web site allows partner institutions to manage security, marketing
and customer
support centrally through sophisticated administrative and reporting tools.
To enable the flow of funds between parties, according to the invention,
consolidation
trust accounts are established by each partner financial institution, as shown
in Figures 4a and
4b. Accounts are held for each currency supported by the system. As a result,
no exchange of
funds between partner institutions is necessary to settle individual payments
between
customers. Instead, payments are executed by transferring funds from a
customer's account to
the consolidation trust account at the originating institution. If the payee
is a customer at a
partner institution, receipt of funds is accomplished by transferring movies
in real-time from
the consolidation trust account at the payee's institution to the customer's
account. Funds are
available to the payee for collection immediately after payment notification
is sent.
Collection may be effected by a withdrawal from an ATM.
A front-end Web service allows a payee banking at a non-affiliated institution
to
specify an offline mechanism for payment retrieval. The payee can select the
transfer of
funds to their accounts at CPA and NACHA member institutions (through an EFT
and ACH
processor, respectively) or crediting to most common credit cards through a
remittance
processor or payment gateway, as shown in Figures Sa and Sb. The invention
also offers the
option of a payee requesting delivery of a paper check by traditional mail for
a nominal
processing fee deducted directly from the amount they are receiving. Batch
file payments are
securely transferred to processing agencies on a nightly basis. EFT, ACH and
credit card
disbursements typically talce between one to four business days while check
delivery takes
from five to seven business days for North American delivery.
All communication with "offline" consumers include prompts to drive adoption
of a
partner institution's online banking service. Through a variety of
precautionary measures,
described below, the invention ensures the security and validity of all
payment requests and
disbursements and provides detailed reporting and transaction tracing to its
partner banlcs.
To move money between customers, the invention leverages the existing internal
funds transfer module utilized by institutions to facilitate customer
transfers. With a few
modifications, this piece of middleware (usually located on an application
server) is enabled
_g_
CA 02435909 2003-07-24
WO 02/059847 PCT/CA02/00107
to execute transfers between a customer's account and a consolidation trust
account for
disbursements. The invention operates in reverse at the recipient's end. If a
payee catches a
payment at a partner institution, funds are immediately transferred from a
consolidation trust
account into the payee's own account.
To minimize liability, funds awaiting delivery are stored in accounts at
partner
institutions in each supported currency. The CCF controls the acceptance and
disbursement
of funds in these accounts, but does not take direct ownership of the money.
Instead, the trust
accounts are actually internal or suspense accounts maintained by the partner
institutions,
who earn the float on the funds awaiting disbursement. The CCF provides a
detailed
accounting of all the money flowing in and out of these accounts. The CCF acts
as a control
point, approving financiah transactions undertaken by partner institutions to
move funds
between customer and trust accounts in real-time.
The CCF network, acts as a netting center. Instead of settling each individual
transaction, the CCF becomes a virtual clearinghouse, adding and subtracting
inter-partner
payables and receivables and then providing the partner institutions with
settlement
instructions to balance the trust accounts, as shown in Figure 6.
This netting activity is captured by a robust, double-entry accounting system.
A
continuous transaction journal at the CCF mirrors each of the trust accounts
maintained at
partner institutions to facilitate auditing and reporting. The system is
designed for resilience
and will catch accounting imbalances caused by the failure of one or more mid-
operation
system processes. The CCF utilizes these accounting and reporting mechanisms
to facilitate
the following activities:
a) Daily reconciliation between the CCF and its partner institutions: The CCF
matches
transactions in its journah against those tracked by each partner institution
and then reports
any exceptions. Exception reports are investigated and addressed to ensure
that accounts are
balanced.
b) Daily settlement reporting for partner institutions. The CCF calculates
monetary
obligations of each partner institution to all other partner institutions in
the network based on
the origin and destination of completed payments. Each partner institution is
provided with a
detail list of all corresponding payments as well as a summary of movies owed
to the other
-9-
CA 02435909 2003-07-24
WO 02/059847 PCT/CA02/00107
partners. Partner institutions settle with each other outside of the CCF by
using existing large
value fund transfer mechanisms available in their jurisdiction.
c) Feed the CCF's finance and accounting systems: The transaction journal
generates a
number of accounting and control system reports.
d) Provide audit reports: Where an audit is required, the CCF uses the
transaction journal to
generate accounting reports for all funds that have yet to be disbursed. The
CCF also retains
historical records to facilitate account investigations.
e) Exception reporting: Partner institutions can send their client fund
transaction log
(covering activity in their consolidation trust accounts) to the CCF to match
these against the
transaction journal for inconsistencies. If the two reports do not balance, an
exception report
is generated so that the situation can be investigated immediately and
corrected if necessary.
Where the payer and payee are located in different jurisdictions, requiring a
currency
exchange, the settlement procedure incorporates a foreign exchange facility
which maintains
trust accounts in each jurisdiction in the local currency.
Figure 7 illustrates the payer and payee navigation paths where both payer and
payee
are existing clients with Web banking privileges at partner financial
institutions.
As shown in Figure 8, the invention provides an identity management system
that
leverages secure payment relationships between remote consumers. Each customer
(payer or
payee) is granted a unique identity that is assigned when he or she first
registers with the
service. A payer can establish a list of recurring personal payees as
required. While payee
records are immediately added to the CCF database, they are not authenticated
until they
correctly answer one or more challenge-response questions defined by the payer
and after
successfully logging onto his or her institution's online banking service or
other delivery
channel. This process establishes both the payee and the specific "channel"
where the payee
has opted to deposit funds. If a customer wishes to credit an account at
another institution on
a subsequent transaction, the customer must re-authenticate with the original
challenge-
response questions before that new "channel" is secured. The challenge-
response questions
may include the input of a secret code provided by the payer to the payee. In
another
embodiment, identity management is handled entirely by the authentication
procedures of the
partner institutions, thus allowing the institutions to manage the risk of
fraud entirely by
-10-
CA 02435909 2003-07-24
WO 02/059847 PCT/CA02/00107
implementing their own security standards without the use of a payer-defined
challenge-
response question.
The identity management aspect of the invention provides the following
advantages:
a) Increased system security: Customer account information from partner
institutions is never
stored at the CCF facility. The CCF completes all processing against its own
internal IDs,
which are established when each customer auto-enrolls to send payments. Each
CCF internal
ID is referenced against an institution's customer user ID for message
synchronization.
b) Transaction tracing: The CCF holds a unique identifier for each customer it
encounters.
The CCF layers contact information for each customer identity in its database
to facilitate
notifications and authorizations. Each identity is cross-referenced back to
the partner
institutions' customer IDs to facilitate transactions, reporting, support and
traclcing without
compromising personal information.
c) Enhanced consmner experience: The identity management model of the
invention enables
customers to retain "trusted" payment relationships to simplify future
payments. These payee
relationships are delivered on demand to a partner's system to encourage quick
re-use of the
"trusted" payee for subsequent transactions, thereby enhancing the user
experience. These
payee relationships can be deployed to other bank channels, such as WAP-
enabled phones,
through the message interface, to launch subsequent payments first established
through a
partner's Web banking service.
d) The consumer is validated on each channel before moving funds: Since the
payment
system offers customers a variety of mechanisms for "catching" payments, one
may choose
an account at a different partner institution into which funds are deposited
on a subsequent
visit. In this case, the payment system again asks the same challenge-response
questions
before validating the new payment channel, at which point the new account is
deemed
"trusted" and added to the consumer's identity.
Through the identity management function, other fraud protection and security
measures are employed by the payment system in addition to the authentication
of payment
relationships.
-11-
CA 02435909 2003-07-24
WO 02/059847 PCT/CA02/00107
a) Institution-controlled security parameters: Each institution can define
security parameters
that govern transactions originating from their banking service. These default
parameters
include transaction limits, daily transaction limits per customer and the
maximum number of
days before an unretrieved payment is sent back to the payer for recrediting.
b) Initiation of payments: All payments originate from within an authenticated
banking
environment (for example, web, telephone, wireless network, ATM, or another
access point
to banking services) at a partner financial institution. One cal initiate an
email payment only
when logged on, ensuring that such transactions are validated baclc to
customer bank accounts
at partner institutions.
c) Receiving payments: The recipient must authenticate and correctly answer
one or more
challenge-response questions before the retrieval of funds is allowed. The
partner institution
controls the number and type of challenge-response questions the payee must
answer before
the relationship is authenticated.
d) Audit trail: A detailed audit trail records all pending and historical
payments.
e) Transaction integrity: The CCF's transaction management service guarantees
that database
transactions are completed accurately. If any one operation fails, the entire
set of operations is
rolled baclc. A global transaction identifier is created when a client
application initiates a
transaction. The transaction service monitors participants for failures and
inactivity. Records
accessed during a transaction are locked until its completion. A rollback
procedure is
executed when a transaction must be stopped due to unexpected client
termination,
server/networlc failure or other events that may interrupt end-to-end
completion of the
transaction. This procedure checks recently active transactions and then
determines whether it
should be rolled back or committed.
A number of measures ensure the security of customer data. The CCF does not
store a
partner institution's customer account numbers. Data related to customers
banking at
unaffiliated institutions are stored in a secure database, which is located
behind a firewall and
encryption processes. Administrative user IDs and passwords are stored behind
a firewall in
am encrypted format. Administrative users can define multiple security groups
and access
restrictions in accordance to job function. Challenge-response questions
provide an extra
mechanism for authenticating the payee in addition to existing logon processes
at the payee's
own Web banking service. The network connecting partner institutions,
administrative users
-12-
CA 02435909 2003-07-24
WO 02/059847 PCT/CA02/00107
and unaffiliated consumers is divided into several isolation and security
zones with restricted
access among zones. Industry-standard measures are used throughout the network
to ensure
security. Intrusion detection devices, traffic encryption, packet inspection
and application
proxies minimize risk to the network. All communications between the CCF and
its partner
institutions take place over a dedicated line or VPN and are encrypted.
A number of exception processes and error handling mechanisms further ensure
the
CCF's integrity:
a) Undeliverable payments: If the payer specifies an invalid email address and
the resulting
notification bounces baclc to the server, the payer is automatically contacted
and presented the
d
option to re-credit his or her account or correct the recipient's email
address to resend the
payment notification.
b) Unretrieved (or expired) payments: With the CCF's back-office
administration tool,
affiliate institutions can each define a maximum period of time before a
payment expires if
uncollected by a payee. ~n a daily basis, the system will run a task to detect
all expired
payments. Notifications are sent to the payer and payee indicating expiration.
The payer is
then presented with the option to send it again or transfer the funds back
into a specified
account.
c) Cancelled payments: At any time before retrieval, the payer can cancel a
payment. After
logging on to the originating Web banking facility or other delivery channel,
the payer simply
cancels the payment transaction by indicating the account to be credited and
sending an
optional memo indicating why the payment was cancelled. The institution's
banking service
then sends a message to the CCF containing the payment reference number. The
CCF will
verify that the payee has not retrieved the funds and the system will change
the payment
status to 'Cancelled' while sending notification to the payee.
d) Rejected payments: The payee can reject a payment transaction from within
the
authenticated Web banking environment of an affiliate institution or upon
authentication at
the CCF Web site. If the payment is rejected, an email is sent to the payer
with instructions to
log on to his or her Web banking facility or other delivery channel to select
an account to re-
credit the funds.
-13-
CA 02435909 2003-07-24
WO 02/059847 PCT/CA02/00107
e) Invalid account information: If payees select an offline electronic method
to catch a
payment, there exists the potential that incorrect account information might
have been
entered despite the processes performed at the interface layer. Transactions
that cannot be
completed through the ACH/EFT/RPS processing facilities are returned to the
CCF. The
payee is then notified of the problem and given an opportunity to re-enter the
account
information or specify an alternate means of retrieval. If the subsequent
attempts fail to
deposit the funds into the payee's designated account, the funds are returned
to the payer and
both parties are appropriately notified.
f) Reconciliation process: On a daily basis, each partner institution sends a
file containing all
10,. transfers to and from the partner's consolidation trust accounts. Payment
reference numbers
are reconciled against information stored at the CCF.
With reference to Figure 18, a P2P payment may take place as follows:
To initiate a P2P payment, the customer logs onto the partner institution's
online
banking service via the web, telephone, wireless network, ATM (as shown in
Figure 18), or
other means. The customer selects the payment feature from the financial
institution's menu
of services and chooses from their list of prior payees. To enter a new
recipient, the customer
is prompted to enter the payee's name and e-mail address, if notification of
the payment is to
be delivered by e-mail to the payee. The customer specifies payment amount,
the account
from which to draw the funds are specified, and optionally an expiry date and
a personalized
message to the recipient. To add an additional security measure to validate
the recipient
before funds axe disbursed, the customer can create one or more challenge-
response questions
and provide the requisite answers. If the customer logs on using an ATM, these
payment
details axe communicated from the ATM to the ATM switch. As well, the customer
is
authenticated using the institution's security standards; where the customer
logs onto an
ATM, authentication of the customer is handled by the ATM switch in
communication with
the host system of the banl~ing service. The payment details axe cormnunicated
by the ATM
switch to the CCF, wluch assigns a unique payment reference number and
communicates this
number to the ATM switch. The ATM switch then communicates with the host
system, and
the customer's account is debited for the payment and the financial
institution's trust
suspense account is correspondingly credited. The ATM switch communicates with
the
ATM to cause the ATM to provide a receipt to the customer, which includes the
payment
-14-
CA 02435909 2003-07-24
WO 02/059847 PCT/CA02/00107
reference number, then communicates the successful completion of this portion
of the
transaction to the CCF. Notification is delivered to the recipient announcing
the payment.
The recipient's personalized notification indicates the amount being paid,
from whom,
the name of the originating institution, as well as options for collection. In
one embodiment,
the notification takes the form of a personalized e-mail to the recipient, as
shown in Figure
10. The payment's originating institution may promote its services through
banner
advertisements in the body of the message. The invention provides multiple
options for
retrieving funds, as shown in Figure 11.
If the recipient already banks online with a partner institution and has
previously
received an electronic payment via this system, the recipient may select from
a list of
payment options to log onto their online bank account straight from a liu~
provided in the e-
mail notification of payment, optionally identifies the payment by reference
number and
answer the challenge-response question if it is the first payment from that
particular sender.
This validates the relationship between both parties. The recipient may choose
to log onto
their online bank account using another communications protocol, such as via a
wireless
network , telephone, or ATM.
If the recipient banks online with a partner institution, but is receiving a
P2P payment
for the very first time, a link in the e-mail notification sends the customer
to a directory of
CCF partner institutions. Recipients can use their online banking service to
instantly credit
any of their accounts. The registration process is fully automated.
Recipients, who are not currently banlung online, are prompted to either "Web
enable" their existing accounts at a CCF partner institution (such as the
sender's bank) or
apply for an account with online access at another partner, as shown in Figure
12. To
facilitate this process, the CCF Web site provides aII appropriate Iinlcs and
information.
Currently, the enrollment process for acquiring online banking services at a
financial
institution can take anywhere from a few minutes to a few weeks, especially if
passwords
must be issued by mail. In the case of a delay, the CCF will hold the payment
for the
appropriate number of days; customers must wait for their account to be
activated at a partner
institution. An e-mail reminder is sent to the customer to activate the
service and retrieve
their funds.
-15-
CA 02435909 2003-07-24
WO 02/059847 PCT/CA02/00107
The recipient then selects the account into which to deposit the funds. The
institution
validates the recipient's identity, and communicates the payment details to
the CCF, which
verifies the payment and issues permission to disburse the money. The
financial institution
then debits a suspense account, and credits the recipient's account for the
payment. If the
recipient chooses to receive the funds directly, a cash account is credited
instead and the
funds are disbursed. Once the funds credit or disbursement is completed, the
CCF is
informed of the successful completion. The funds may be advanced immediately
by the
recipient's institution, because the funds have been guaranteed by the
originating institution's
verification of the identity of the sender.
The complete payment transaction is decentralized; the first component, the
initiation
of payment, is controlled by the sender's financial institution, and the
second component of
the transaction, the receipt of the payment, is controlled by the recipient's
institution. It can
also be seen that due to the authentication of each party to the transaction
independently, by
each party's own financial institution, the payer's identity does not need to
be known by the
payee in order to effect payment. The payer may use an alias or e-mail address
only, if
desired, in communication with the payee.
The funds may alternatively be deposited to a credit card or other bank
account. To
provide maximum payment reach, the CCF processes payments to non-partner
accounts on a
fee-for-service basis. Recipients may opt to deposit the payment into a credit
card or other
bank account not sponsored by a partner institution. Recipients are directed
to the CCF Web
site, where they can register for the service. When registered, recipients
specify a credit card
or bank account into which to deposit the funds. Such requests are hatched and
sent each day
to payment processing services to be credited via ACSS, ACH and RPS services.
Payment recipients who require a checlc or are uncomfortable malting
transactions
online, can request the CCF to issue a paper check for mail delivery. At every
turn, payment
recipients are prompted to use a partner institution to receive their fiuzds.
If they choose to
receive a payment using a non-partner mechanism, the CCF will facilitate the
transaction
through its Web site.
In a further embodiment, payments may be made to a recipient who does not have
a
banlc account via an ATM and is not registered with the CCF. The ATM, rather
than
requiring a banlc card to initiate any transaction, provides direct access to
the menu option to
-16-
CA 02435909 2003-07-24
WO 02/059847 PCT/CA02/00107
receive a P2P payment. To verify the identity of the recipient, since there is
no bank card
authentication, preferably the recipient must at least respond to the
challenge-response
question and/or provide the payment reference number. The ATM will communicate
these
payment details to the CCF, which will verify the payment and issue permission
to disburse
the money.
The CCF's notification server provides information to both parties regarding
the
status of a payment transaction. Each of the messages is based on a standard
template, so that
the payee receives the same message irrespective of the originating partner
institution.
Notifications have multilingual capabilities. Figure 13 shows options for end-
user
notifications generated by the system of the invention.
Payments between businesses and businesses, or between businesses and
customers,
follow the same format as the payments described above. However, if a large
number of
payments are transacted, it becomes impracticable for a business to log on and
collect each
payment as they arrive. Instead, business customers of participating
institutions may enroll in
a commercial registry which provides a funds consolidation function.
Business customers who choose to participate in the commercial registry are
first
qualified for participation and enrolled by their institution. The institution
in turn provides
this certified business customer information to a CCF commercial registry,
which is used to
validate and certify the identity and contact information of the business
company as a
legitimate operating concern with a bona fide banking relationship when
payment
transactions are initiated. Preferably, this information will include the
official name, address,
and contact information of the business, trade name, and a verified e-mail
address.
A subset of this financial institution-certified information is available to
any
individual or business that receives a payment request or wishes to originate
a merchant
payment to this business customer, which provides assurance that the funds are
being directed
to the appropriate recipient.
A business customer may generate a payment request for one of its own
customers by
delivering an invoice and directing the customer to access his or her own
financial institution
services to effect payment to the business as shown in Figure 19. The business
customer logs
onto its partner institution's ovine banking service and enters invoice data
either manually or
by importing a payment file from a third party accounting tool. The partner
institution
-17-
CA 02435909 2003-07-24
WO 02/059847 PCT/CA02/00107
transfers the payment details to the CCF, which assigns a tracking number and
optionally a
universal resource locator (URL). The payment details are stored by the CCF,
which then
notifies the customer (payer) of the invoice. Preferably, the invoice is
delivered by e-mail
and directs the customer to its partner institution's online banking service.
The customer may
choose to approve payment immediately, or may choose to view additional
information
regarding the invoice if such information is available (for example, through
the URL or
another hyperlinlc). When the payment is approved, the CCF completes the
payment in the
manner described above and issues a receipt to both parties. The business
customer can then
log onto its institution's online banking service to collect the funds and
optionally export
transaction statements to a third party accounting tool.
In another embodiment, shown in Figure 20, no invoice is issued to the
customer, but
the customer initiates the payment as part of a retail transaction in an
online environment.
For example, in a web-based auction, the customer clicks on a "pay me" link
appearing in a
vendor's auction listing. Clicking on this link passes payment details to the
CCF, together
with a token identifying the vendor and an optional return URL. In the
meantime, the
customer is referred to a partner institution, approves the transaction, and
the payment is
completed as generally described above.
When the payment is made, the business customer can choose to receive
notification
of each payment, and choose a deposit account and collect the funds.
Alternatively, because
it is impractical for the business customer to respond in this mamier to a
large number of
payments, the payment system can be configured to consolidate funds by
accumulating
cleared payments, and then sweeping the accumulated funds into a default
commercial
account at the end of the period. The funds may be swept into the commercial
account on a
periodic basis, such as a daily basis, or once the accumulated funds reach a
certain threshold
value or the number of payments reaches a threshold number.
Business-to-business payments, for example, payment by a business customer to
a
supplier, may also be effected using this system. If the recipient business is
also enrolled in
the commercial registry, the CCF will handle the payment using the funds
consolidation
method.To enable transactions between two or more payment systems, for example
two
domestic payment systems in a cross-border transaction, the financial
institutions in each
country are affiliated with a regional CCF in that country. Customers in each
country use
their partner institution's authentication process to Iog into their selected
delivery channel
-18-
CA 02435909 2003-07-24
WO 02/059847 PCT/CA02/00107
(Internet, telephone, ATM, wireless, etc.). Each regional CCF is responsible
for storing,
sending and receiving all payments which originate and terminate at that site.
Only a limited
amount of data is replicated between the regional sites when it is required to
perform a
function. Preferably, any replication is carried out based on an asynchronous
remote XML
request, which carries the data to be replicated. There is therefore no
requirement for real
time data synchronization between regional CCF sites.
An international CCF site is primarily responsible for coordinating the
exchange of
data between the regional CCF sites. The international CCF also maintains a
global directory
of affiliated institutions. A foreign exchange (FX) facility maintains a
database of exchange
rates and manages currency exchange transactions, and maintains trust accounts
in each
jurisdiction in the local currency.
For an international payment, the CCF switch at the point of origin of the
payment
queries the global directory to determine which institution and CCF regional
switch has been
designated by the recipient. If a currency exchange is required, the CCF
switch at the point
of origin also communicates with an FX facility to determine the exchange rate
and book the
currency exchange. The payment details are replicated by the regional CCF to
the regional
CCF of the recipient using an asynchronous messaging mechanism.
At the point of destination, the regional CCF delivers a payment notification
to the
intended recipient. The notification includes an encrypted payment reference
number, which
contains a payment identification code to identify the payment's point of
origin. The
notification directs the recipient to an affiliate institution to claim the
payment. The recipient
logs onto the selected banking service and receives the funds. Funds transfer
occurs by
means of transfers between suspense accounts and customer accounts, as
described above.
Settlement between financial institutions takes place on a periodic basis, for
example
at the end of each business day. Based on agreed cut-off times, the CCF
provides each
member institution with reconciliation and settlement information. This data
is used to
reconcile transactions between the CCF and each institution, as well as to
determine the
institution's monetary obligations to other members in the network to effect
settlement.
Where the institutions are located in different jurisdictions, settlement
takes place
between the originating and destination institutions using the exchange
settlement facility's
accounts in the jurisdiction of each institution, based on settlement advice
provided by the
-19-
CA 02435909 2003-07-24
WO 02/059847 PCT/CA02/00107
CCF. With reference to Figure 21, the international CCF site is networked to a
number of
regional CCF sites. The participating financial institutions in each region
are connected to its
corresponding regional switch. Each of these institutions maintains a suspense
account. The
FX facility has an international site networked with local sites, which are in
communication
with each of the institutions in the same region. Each local FX site maintains
a local currency
settlement trust account on behalf of the international CCF, through which all
foreign
exchange settlement will take place.
The networked CCFs provide settlement advice to the financial institutions so
that the
institutions may make aggregate transfers. These transfers are made to the
local currency
settlement trust accounts in the local currency, and not to the other
institutions. Each transfer
may be carried out by means of wire payment to provide finality of transfer.
Access to functions beneath the user interface layer is provided utilizing a
request/response XML-based message set. All communications are encrypted and
signed.
Figure 14 illustrates high-level interaction between a partner institution's
middleware and the
CCF facility to reconcile a payment to a new payee. Figure 15 shows a number
of possible
message sets and explains how they are used to facilitate P2P payments. Each
message set
consists of a request initiated by a partner institution's middleware and a
response returned by
the CCF. These messages involve additional system processes at the CCF.
According to the invention, the use of specific delivery channels is left to
the
discretion of the partner institution. While the primary channel is online
bai~lcing, the service
can be extended to telephone banl~ing and host-based ATMs.
Currently, consumers access Web banking services almost exclusively on a
browser
residing on a personal computer. As Internet-enabled appliances gain mass
acceptance and
continue to improve in terms of cost, connectivity, display, memory and
processing
capabilities, financial institutions will offer banking services through these
devices. A single
interface is required between the institution and the CCF to support multiple
Web-enabled
devices. Java-based adapters allow institutions to communicate internally with
other
application servers that support specific devices.
Once financial institutions have implemented P2P payment capabilities on their
Web
banking service, they can utilize the message-based interface of the invention
to support a
synchronized, multi-channel delivery strategy to offer users of non-PC devices
access to the
-20-
CA 02435909 2003-07-24
WO 02/059847 PCT/CA02/00107
same list of personal payees from their Web channel. Due to current data-entry
interface
limitations in mobile devices (such as WAP-enabled cell phones, ATMs and
telephone
banking VRUs), it may be more practical to display a customer's pre-existing
list of personal
payees through these channels. The identity management system of the invention
has the
capability to store lists of customers' established payment linkages from
prior payment
requests.
For example, a consumer wants to re-credit an acquaintance for picking up the
dinner
tab at a restaurant. This payee could log onto their institution's wireless
banking service,
select the payment recipient from his or her list of past personal payees and
enter a monetary
amount and a specific account from which to draw the funds. Upon receipt of
the payment
request, the CCF immediately launches a payment notification and the recipient
can
authenticate to deposit the funds the next time he or she accesses email.
Mobile P2P
payments will help institutions extend their wireless banking platforms,
increase adoption and
leverage their investments in that channel.
Most banks currently offer some form of telephone banking service through an
automated voice response unit (VRU). Typically, customers that authenticate
with a PIN
number can select and pay merchants from a previously determined personal
list. A list of
pre-existing personal payees stored by the CCF is akin to the merchant list
concept in the
previous example and can be presented on the VRU platform through the CCF's
XML
messaging interface.
Similarly to Web and telephone banking delivery, the institution can display a
customer's existing list of personal payees on ATMs for convenient re-use by
leveraging the
messaging interface and identity management system of the invention.
A Web-based publishing tool is supplied with the administration suite enabling
marketing managers at institutions to control the email banners that appear on
these
notifications. The CCF can send notifications to employees within partner
institutions.
Notification functionality is determined by the institution through the CCF's
Web-based
administration and reporting tools.
The invention provides a secure Web-based interface for staff at partner
institutions to
manage customer service, business planning, marketing and key system and
security
-21 -
CA 02435909 2003-07-24
WO 02/059847 PCT/CA02/00107
parameters. Different job categories allow bank staffvarying levels of access
to information
and functions of the invention.
The financial institution's system security administrator possesses root-level
access
that grants privileges to other staff. This administrator can define and
update certain system-
s wide security parameters that govern transactions originating from the
institution's Web
banl~ing service. These parameters include maximum transaction limits, daily
transaction
limits per consumer and the maximum number of days before an unretrieved
payment is sent
baclc to the payer for re-crediting.
An institution's Web service channel manager can publish and update marketing
messages that appear on CCF-triggered email payment notifications. As well,
the channel
manager can view all multilingual email templates delivered to customers to
facilitate
payments and direct customers to URLs that open online banking services or
logon to
existing accounts. This person can also view all system-generated business
metric reports that
yield rich statistics, such as payment volumes, customer activation levels,
methods conswners
use to catch payments, average payment amounts and the average time between
payment
initiation and final settlement.
Customer service representatives (CSRs) can make inquiries using transaction
confirmation codes that facilitate payment tracing. The invention provides a
complete audit
trail for any activity related to a particular customer or payment transaction
within a certain
time period. CSRs can provide support by viewing payment-processing
information. Detailed
lists of system-generated messages (and explanations) as well as daily
schedules for
processing are some of the items that CSRs can access in responding to
customer inquiries.
The system also features CCF bulletin boards to publish messages that could
impact upon
customers' immediate use of the service.
The architecture of the invention, illustrated in Figure 16, provides
performance,
security, availability and scalability. The invention delivers protection from
unauthorized
external or internal access by implementing several industry standard
mechanisms including:
multi-layer firewall structure; secure access lockdown of Web servers and mail
servers;
extensive intrusion detection; documentation security and escalation
procedures. The
invention supports a cluster server architecture designed to provide maximum
fault tolerance,
performance and scalability.
-22-
CA 02435909 2003-07-24
WO 02/059847 PCT/CA02/00107
The invention uses XML based request/response messaging to exchange
information
with financial institutions. Each XML message consists of a standard header
and variable
body sections. The system is designed to support versioning and to be
baclcwards compatible
as new features are added or new means of access to online banking are
provided to
customers. For example, where an institution requests a payment transaction on
behalf of its
client the financial institution's own Internet banking application presents
the appropriate
form to the customer, gathers and validates the data entered by the customer
and formats the
XML request such as:
<?xml version = "1.0" encoding="utf 8"?>
<!DOCTYPE REQPMTBGRQ SYSTEM "file://reqpmtbgrq.dtd">
<CCFREQUEST>
<MES SAGEHDR>
<MESSAGETYPE>8<IMESSAGEGETTYPE>
<MES SAGETYPEV ER> 1.1 </MES SAGETYPEVER>
<FIID>10</FIID>
<TRANTOKEN>X3 SJCBE</TRANTOKEN>
</MES SAGEHDR>
<MESSAGEBODY>
<FIUSERID>56450983045034</FIUSERID>
<CUSTOMERID>B7856434U4</CUSTOMERID>
<CURRENCY>CAD</CURRENCY>
<PMTAMOUNT>65.00</PMTAMOUNT>
<EXPIRYDATE>2000-09-16-23:59:00.000000</EXPIRYDATE>
<MEMO>Here is the money I owe you for dinner. Thanks</MEMO>
- 23 -
CA 02435909 2003-07-24
WO 02/059847 PCT/CA02/00107
</MESSAGEBODY>
</CCFREQUEST>
The invention executes the appropriate transaction and return a response to
the Financial
Institution using a similar format.
The preferred production system runs on a hardware platform under the Unix
Operating System and uses commercially available and reliable Application and
Database
Management Software. The system is housed in data center facility. The
preferred
embodiment of the invention employs Java 2 Enterprise Edition technology
coupled with an
enterprise relational database system using a clustered, fault-tolerant
configuration which is
both scalable a,nd extensible, providing the ability to easily manage and
update with
additional features and services as required.
Applying mufti-tier distributed design patterns, the invention is composed of
four
logical service items (presentation, messaging, business and data), shown in
Figure 17, that
are physically distributed through several redundant, fault-tolerant and
balanced
implementation systems. Presentation logic is the linlc between the client
interface and the
business logic. Using JavaBean and Servlet specifications, the presentation
logic components
communicate with the business logic components (EJBs). The presentation logic
is based on
the concept of heterogeneous client interfaces, allowing both browser and non-
browser
interfaces to cormnunicate with the CCF. The messaging layer is the link
between the partner
institution and the business logic. This layer consists of a number of Java
servlets responsible
for parsing and validating XML messages and the invocation of appropriate
business
components. Business logic is processed by a distributed middleware server
with enabled
clustering and object caching based on the Enterprise JavaBean standard. Both
business logic
and functional rules are maintained in a eries of session beans and entity
beans that are
located on networked systems. Enterprise JavaBeans (EJBs) communicate with the
associated
data media and apply any relevant business rules. Data media and its
associated transactions
are maintained in an enterprise database system supporting both the encryption
of resident
data and the features that promote redundancy and reliability.
The following technologies may be employed in the implementation of the system
and method of the invention:
-24-
CA 02435909 2003-07-24
WO 02/059847 PCT/CA02/00107
Java 2 Standard Edition
JavaTM 2Standard Edition (J2SETM) is a Web platform that enables rapid
development and
deployment of software applications across multiple operating systems and
platforms with
fewer defects than similar technologies. With significant performance gains
and improved
Web deployment mechanisms for enterprise, client-side Java applets and
applications, J2SE
Version 1.3 includes a new client Java virtual machine (JVMTM), tuned
libraries throughout
the platform and enhancements to the Java Plug-in software for improved Web
browser
delivery.
Java Beans
Developed in collaboration with industry leaders, JavaBeans are a portable,
platform-
independent component model written in Java. JavaBeans enable developers to
write reusable
components once and run them anywhere independent of platform.
Java 2 Enterprise Edition
The JavaTM 2 Platform, Enterprise Edition (J2EE), defines the standard for
developing multi-
tier enterprise applications. J2EE simplifies enterprise applications by
basing them on
standardized, modular components, providing a complete set of services to
those components
and handling many application behavior details without complex programming.
J2EE takes
advantage of many Java 2 Platform, Standard Edition, such as "Write Once, Run
AnywhereTM" portability, JDBCTM API for database access, CORBA technology for
interaction with existing enterprise resources and a security model that
protects data even in
Internet applications. Building on this base, Java 2, Enterprise Edition, adds
full support for
Enterprise JavaBeansTM components, Java Servlets API, JavaServer PagesTM and
XML
technology.
Java Server Pages
The 3avaServer PagesTM technology provides a quick and simple way to create
dynamic Web
content while enabling rapid development of Web-based applications that are
server- and
platform-independent. The JavaTM Servlet API provides Web application
developers with a
simple and consistent mechanism for extending Web server functionality.
Enterprise Java Beans
The Enterprise JavaBeans specification defines an API that helps developers
create, deploy
- 25 -
CA 02435909 2003-07-24
WO 02/059847 PCT/CA02/00107
and manage cross-platform, component-based enterprise applications that work
with systems
currently in use.
Java Naming and Directory Interface
This provides uniform, industry-standard and seamless connectivity between the
Java
platform and one's business information assets, allowing developers to deliver
Java
applications with unified access to multiple naming and directory services
across the
enterprise.
Java Database Connectivity
This provides programmers with a uniform interface to a wide range of
relational databases,
as well as a common base upon which higher-level tools and interfaces can be
built.
Java Messaging Services
This specification provides developers with a standard Java API for enterprise
messaging
services, such as reliable queuing, publishing and subscription cormnunication
and vaxious
aspects of push/pull technologies.
Remote Method Iuvocatioh over IIOP
RMI-IIOP provides developers an implementation of the Java RMI API over the
Object
Management Group's industry-standard Internet Inter-Orb Protocol (IIOP). It
allows
developers to write remote interfaces between clients and servers and
implement them using
Java technology and the Java RMI APIs.
XML
XML (eXtensible Markup Language) is a simplified subset of the Standard
Generalized
Markup Language (SGML, ISO 8879) that provides a file format for representing
data, a
schema for describing data structure and a mechanism for extending and
annotating HTML
with semantic information.
Secure Socket Layer API
Secure Sockets Layer (SSL) is the Internet security protocol for point-to-
point connections. It
provides protection against eavesdropping, tampering and forgery. Clients and
servers
establish a secure linlc, or "pipe," across the Internet to protect
information that is sent and
received to ensure confidential, authentic and original information exchange.
-26-
CA 02435909 2003-07-24
WO 02/059847 PCT/CA02/00107
Various embodiments of the present invention having been thus described in
detail by
way of example, it will be apparent to those skilled in the art that
variations and
modifications may be made without departing from the invention. The invention
includes all
such variations and modifications as fall within the scope of the appended
claims.
