U.S. patent application number 13/619830 was filed with the patent office on 2013-01-10 for global remittance platform.
This patent application is currently assigned to Wells Fargo Bank, NA. Invention is credited to Daniel I. Ayala, Eugene Gutierrez.
Application Number | 20130013497 13/619830 |
Document ID | / |
Family ID | 36319710 |
Filed Date | 2013-01-10 |
United States Patent
Application |
20130013497 |
Kind Code |
A1 |
Ayala; Daniel I. ; et
al. |
January 10, 2013 |
GLOBAL REMITTANCE PLATFORM
Abstract
The invention provides a remittance platform in which an
enterprise, such as Wells Fargo, serves as a remittance transfer
agent, where the remittance function is integrated with a bank. The
invention allows access to the remittance program by both account
holders with the enterprise and persons who do not have an account
with the enterprise. The person accessing the service may pick the
remittance service they want and the country they want. However,
the service is not anchored to a particular account and can
therefore work with both bank partners and non-bank partners and
account holders and non-account holders. Further, the system may be
private-labeled. Additionally, the invention provides a mechanism
that allows one to send money easily to other countries and it
allows bank partners to participate in the program easily as well.
This is possible because the enterprise provides all of the
processing in an integrated fashion.
Inventors: |
Ayala; Daniel I.; (Antioch,
CA) ; Gutierrez; Eugene; (San Francisco, CA) |
Assignee: |
Wells Fargo Bank, NA
|
Family ID: |
36319710 |
Appl. No.: |
13/619830 |
Filed: |
September 14, 2012 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11260962 |
Oct 27, 2005 |
|
|
|
13619830 |
|
|
|
|
60623198 |
Oct 29, 2004 |
|
|
|
Current U.S.
Class: |
705/39 |
Current CPC
Class: |
G06Q 40/00 20130101;
G06Q 40/02 20130101 |
Class at
Publication: |
705/39 |
International
Class: |
G06Q 20/10 20120101
G06Q020/10 |
Claims
1. A method for remitting funds from a remitter to a beneficiary,
comprising: maintaining a database associated with a bank account
for a remitter at a bank, the bank associated with an enterprise;
receiving transaction data for a remittance transaction, the
transaction associated with providing funds from the remitter to
the beneficiary; retrieving the funds from the bank account of the
remitter; and making the funds available to the beneficiary in the
form of cash; wherein the remittance transaction is not anchored to
a particular account of the beneficiary and the beneficiary does
not have an account with the enterprise.
2. The method of claim 1, further comprising: generating a first
reconcile and settlement message using a remittance engine based on
the transaction data and storing the first reconcile and settlement
message in the database; generating a second reconcile and
settlement message based on the transaction data and storing the
second reconcile and settlement message in the database; and
reconciling the first and second reconcile and settlement
messages.
3. The method of claim 2, wherein the funds are retrieved from the
bank account of the remitter upon reconciling the first and second
settlement messages.
4. The method of claim 1, further comprising disclosing an amount
earned by a remittance agent in conjunction with the remittance
transaction to the remitter.
5. The method of claim 1, further comprising providing the remitter
with a plurality of remittance options.
6. The method of claim 5, wherein the plurality of remittance
options include a cash to cash option, an account to cash option, a
cash to account option, and an account to account option.
7. The method of claim 1, wherein the transaction data is received
by a computer-implemented teller system.
8. A method of remitting funds from a remitter to a beneficiary,
comprising: maintaining a bank account for the remitter, the
remitter being a customer of a bank, the bank being associated with
an enterprise; providing the remitter with a plurality of options
for a remittance transaction to remit the funds, the plurality of
options including an account-to-cash remittance transaction;
receiving instructions from the remitter relating to the remittance
transaction, the instructions including a selection of the
account-to-cash option; withdrawing funds from the bank account of
the remitter based on the instructions; and transferring the funds
to the beneficiary using a computer network; wherein the remittance
transaction is not anchored to a particular account of the
beneficiary and the beneficiary does not have an account with the
enterprise.
9. The method of claim 8, wherein the plurality of options further
comprises an account-to-account remittance transaction, a
cash-to-cash remittance transaction, and a cash-to-account
remittance transaction.
10. The method of claim 8, further comprising providing a
transaction disclosure receipt that provides details regarding the
remittance transaction based on the transaction data.
11. The method of claim 10, wherein the details regarding the
transaction comprise an amount earned by a remittance agent in
conjunction with the remittance transaction to the remitter.
12. The method of claim 8, wherein the instructions are received by
a computer-implemented teller system.
13. The method of claim 12, wherein the computer-implemented teller
system is operated by a human bank teller.
14. The method of claim 8, further comprising: generating a first
reconcile and settlement message using a remittance engine based on
the transaction data and storing the first reconcile and settlement
message in a database; generating a second reconcile and settlement
message based on the transaction data and storing the second
reconcile and settlement message in the database; reconciling the
first and second reconcile and settlement messages.
15. A system configured to remit funds from a remitter to a
beneficiary, the system being provided by an enterprise, the system
comprising: a computer-implemented teller configured to receive
transaction data for a remittance transaction; a database
configured to store the transaction data and account data for bank
accounts associated with account holders; and a remittance system
coupled to the computer-implemented teller and the database and
configured to support a plurality of types of remittance
transactions including account to cash transactions; wherein for
account-to-cash transactions, the funds are retrieved from one of
the bank accounts, the account-to-cash transaction is not anchored
to a particular account of the beneficiary, and the beneficiary
does not have an account with the enterprise.
16. The system of claim 15, wherein the system is further
configured to support cash-to-cash, cash-to-account, and
account-to-account remittance transactions.
17. The system of claim 15, further comprising: a remittance
network member account configured to reconcile and settle the
remittance transaction based on the transaction data; an
international remittance engine (IRE) configured to create a first
output file in a predetermined message format and to output the
first output file to an external remittance network member system
based on the transaction data; an enterprise remittance general
ledger system configured to receive a second output file from the
IRE and send a reconcile and settlement message to the remittance
network member account for reconcilement and settlement based on
the second output file; and a demand deposit account configured to
receive funds associated with the remittance transaction from the
enterprise remittance general ledger system resulting in the funds
being available in the external remittance network member
system.
18. The system of claim 17, wherein the IRE maintains and provides
information related to countries comprising: country; bank;
currency supported; and methods available to receive funds.
19. The system of claim 17, wherein the enterprise financial
system, remittance member network account, IRE, enterprise
remittance general ledger system, and the demand deposit account
are all provided as part of an integrated remittance
enterprise.
20. The system of claim 15, wherein the remittance system provides
the remitter with an amount earned by the integrated remittance
enterprise in conjunction with the remittance transaction.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims priority to U.S. Provisional Patent
Application Ser. No. 60/623,198, filed on Oct. 29, 2004, Attorney
Docket Number WELL0048PR, which application is incorporated herein
in its entirety by the reference thereto.
BACKGROUND OF THE INVENTION
[0002] 1. Technical Field
[0003] The invention relates to remittances. More particularly, the
invention relates to a system and process for a global remittance
platform not anchored to a particular account and can therefore
work with both bank partners and non-bank partners, and account
holders and non-account holders.
[0004] 2. Description of the Prior Art
[0005] With the advent of the information age and of the Internet,
globalization is affecting many aspects of an individual's
lifestyle. As each decade passes, previously unimaginable
improvements are created upon the previous decade's advances. With
respect to increased global mobility, workers are finding
themselves working in one country but wanting to deposit a portion
of or all of their income into an account in a different country,
typically the country of origin.
[0006] It is possible today for a bank customer to open an account
in a first bank in a first country that has a business relationship
with a second bank in a second country. It is possible for same
customer to link the first account to a second account in the
second bank so that an international deposit, or remittance, can be
effected. Of course, the transfer of funds has to take into account
exchange rates, domestic and international regulation and
compliance, and so on.
[0007] H. Jennings, N. Pinnell, K. Do, V. Shah, M. Profumo, J.
Downing, N. Goodhand, M. Maino, and M. H. Thompson, U.S. Pat. No.
5,659,165, CUSTOMER-DIRECTED, AUTOMATED PROCESS FOR TRANSFERRING
FUNDS BETWEEN ACCOUNTS VIA A COMMUNICATIONS NETWORK, (Aug. 19,
1997) discusses a way to transfer funds between accounts via a
communications network and, in particular, across international
borders and in different currencies. Jennings et al discuss a
system for transferring funds instantly to an account maintained in
the same or another bank business through the use of a terminal
such as an ATM, home banking phone, personal computer, conventional
telephone or the like. The system allows funds to be transferred to
an account based on customer information, which can be
automatically accessed by the system, rather than needing to be
manually entered. Further, the system automatically computes the
appropriate exchange rate and any fees to be charged to the account
and displays them to the user so that the user may authorize or
cancel the transaction. The disclosure discusses analyzing the
parameters of the transfer for conformance with pertinent
government regulations. The disclosure discusses the user to
quantify the amount to be transferred in the currency of the
originating account or the currency of the receiving account. The
disclosure discusses being designed so that it can be understood
and accessed by individuals having no special expertise in
computers, wire transfers and the like. Finally, the disclosure
discusses various safeguards to assure that only authorized
individuals have access to the accounts and the funds. However, the
teachings require an account-to-account transfer.
[0008] Currently, it is also possible that an individual can
transfer a particular amount of cash in a single transaction to an
associated site in a second and different country where a second
individual can retrieve the cash, assuming incorporating an
exchange rate and other requirements. As example of such a business
is Western Union, owned by Western Union Holdings, Inc.
[0009] However, people are getting increasingly savvy and expect
almost instant gratification. They want more options and without
hassles.
[0010] It would be advantageous to provide an integrated system and
process that is more flexible and integrates and offers an anything
to anything type of remittance.
[0011] It would be advantageous to provide an integrated system and
process that is more flexible and integrates and offers any of the
following types of global remittances: account to account, account
to cash, cash to account, and cash to cash.
[0012] It would further be advantageous for such an integrated
system and process to allow bank partners of an enterprise to
participate in a global remittance program.
[0013] It would further be advantageous for such an integrated
system and process to be private-labeled, e.g. on behalf of the
bank but using the infrastructure of the enterprise.
[0014] It would further be advantageous for such an integrated
system and process to provide a dynamic transaction disclosure
receipt (DTDR) that provides all the details of an individual's
transaction.
SUMMARY OF THE INVENTION
[0015] The invention provides a remittance platform in which an
enterprise, such as Wells Fargo, serves as a remittance transfer
agent, where the remittance function is integrated with a bank. The
invention allows access to the remittance program by both account
holders with the enterprise and persons who do not have an account
with the enterprise. The person accessing the service may pick the
remittance service they want and the country they want. However,
the service is not anchored to a particular account and can
therefore work with both bank partners and non-bank partners and
account holders and non-account holders. The service is an
Anything-to-Anything remittance service. Further, the system may be
private-labeled. Additionally, the invention provides a mechanism
that allows one to send money easily to other countries and it
allows bank partners to participate in the program easily as well.
This is possible because the enterprise provides all of the
processing in an integrated fashion.
BRIEF DESCRIPTION OF THE DRAWINGS
[0016] FIG. 1 is a block schematic diagram showing a system
according to the invention;
[0017] FIG. 2 is a block schematic diagram showing. a system
according to the invention;
[0018] FIGS. 3A-3D show a flow chart showing a cash-to-cash
transfer process according to the invention;
[0019] FIGS. 4A-4D show a flow chart showing a cash-to-account
transfer process according to the invention;
[0020] FIGS. 5A-5D show a flow chart showing an account-to-cash
transfer process according to the invention;
[0021] FIG. 6 is a flow chart showing an account-to-cash set-up
process according to the invention;
[0022] FIG. 7 is a flow chart showing a cash-to-account set-up
process according to the invention;
[0023] FIG. 8 is a flow chart showing an account set-up process
according to the invention;
[0024] FIGS. 9A-9C show a flow chart showing a phone bank account
transfer process according to the invention; and
[0025] FIG. 10 is a schematic diagram of a global remittance
architecture according to the invention.
DETAILED DESCRIPTION OF THE INVENTION
[0026] The invention provides a remittance platform in which an
enterprise, such as Wells Fargo, serves as a remittance transfer
agent, where the remittance function is integrated with a bank. The
invention allows access to the remittance program by both account
holders with the enterprise and persons who do not have an account
with the enterprise. The person accessing the service may pick the
remittance service they want and the country they want. However,
the service is not anchored to a particular account and can
therefore work with both bank partners and non-bank partners and
account holders and non-account holders. The service is an
Anything-to-Anything remittance service. Further, the system may be
private-labeled. Additionally, the invention provides a mechanism
that allows one to send money easily to other countries and it
allows bank partners to participate in the program easily as well.
This is possible because the enterprise provides all of the
processing in an integrated fashion.
[0027] One embodiment of the invention can be described with
reference to FIG. 1, is a block diagram showing an overview of the
system 100. A customer can enter a branch of an enterprise, such as
Wells Fargo, or call up the enterprise's phone bank to creates a
foreign exchange remittance transaction 102. If the customer walks
into the branch office, then the remittance transaction is made
using a global remittance platform, also referred to herein as
Store Vision Teller (SVT) 104 as described hereinbelow. Otherwise,
the customer calls into the phone bank 106 to initiate a remittance
transaction. The request for the foreign exchange remittance
transaction is sent in the form of a message to the enterprise
financial system 108. The enterprise financial system 108 sends
reconcile and settlement messages including the transactional
information to a remittance network member account 110 for
verification. Such account resides in the enterprise
infrastructure. As well, the enterprise financial system 108 sends
the transactional information to an international remittance engine
(IRE) 112 that is also part of the enterprise infrastructure. The
IRE sends the transactional information outside of the enterprise
infrastructure via SWIFT, MQ, or other proprietary messaging
functionality, in a remittance network member file 114. Such file
114 is authenticated and received by an associated remittance
network member system 116. As well, the IRE sends the transactional
information to the enterprise's remittance general ledger (GL)
system 118. The enterprise remittance GL system 118 processes the
transaction informational and sends a different reconcile and
settlement message to the enterprise remittance network member
account 110. It should be appreciated that the transactional
information sent to the remittance network member account 110 from
both the enterprise financial system 108 and the enterprise
remittance GL system 118 should match. If they match, the
enterprise remittance GL system 118 makes funds available on an
aggregate level in the actual demand deposit account 120.
[0028] It should be appreciated that for ease of understanding, the
global remittance platform 104 is used herein interchangeably as
Store Vision Tell (SVT). The global remittance platform comprises
middleware subsystems and enterprise teller functions. SVT can be
thought of as a specific system which the tellers use to start a
transaction, but there are other middleware subsystems that can
facilitate gathering other information. An example of a middleware
subsystem is a system used to determine account eligibility and the
like. Collectively, such middleware subsystems, teller actions
using such systems can be referred to as SVT, global remittance
platform, or teller using SVT.
[0029] One embodiment of the invention can be described with
reference to FIG. 2, a block diagram showing an overview of the
system 200. FIG. 2 is similar to FIG. 1, but showing different
detail. A customer can enter a branch of an enterprise, such as
Wells Fargo, or call up the enterprise's phone bank to creates a
foreign exchange remittance transaction 102. If the customer walks
into the branch office, then the remittance transaction is made
using a Store Vision Teller (SVT) system and method 104. Otherwise,
the customer calls into the phone bank 106 to initiate a remittance
transaction. The request for the foreign exchange remittance
transaction is sent in the form of a message to a financial system
component 202. The financial system component 202 sends a reconcile
and settlement message including the transactional information to a
remittance network member account 110 for verification. Such
account resides in the enterprise infrastructure. As well, the
enterprise financial system 108 sends the transactional information
to an international remittance engine (IRE) 112 that is also part
of the enterprise infrastructure. The IRE sends the transactional
information and instructions outside of the enterprise
infrastructure via a SWIFT file 114a to an MQ or other proprietary
messaging file 114b. Such file 114b is authenticated and received
by an associated remittance network member system 116. As well, the
IRE sends the transactional information to the enterprise's
remittance general ledger (GL) system or aggregator system 118. The
enterprise remittance GL system or aggregator system 118 processes
the transaction informational and sends a different reconcile and
settlement message to the enterprise remittance network member
account 110. The aggregator system 118 sends the transactional
information to the enterprise's internal international systems,
shown herein as component A 118a and component B 118b. The
international system component B 118b sends another reconcile and
settlement message to the remittance network member account 110. It
should be appreciated that the transactional information sent to
the remittance network member account 110 from each enterprise
system, the financial system component 202, the enterprise
remittance GL system 118, and the enterprise international system
component B, should match. If they match, the enterprise remittance
GL system 118 makes funds available on an aggregate level in the
actual demand deposit account 120. The remittance network member
sends a statement 204 to the demand deposit account.
[0030] It should be appreciated that the IRE 112 maintains and
provides information related to the countries and banks that are
set up for a global remittance platform, such as for example,
country, bank, currency supported, and methods available to receive
funds. Such information can be used by a calling channel, such as
SVT or SVP, described in detail hereinbelow, to ensure that only
the information that is supported by a specific bank is made
available, such as in a drop down list.
[0031] Further, the IRE offers business services: a foreign
exchange (FX) calculator and a remittance modeling service that
calls the FX calculator. IRE supports remittance messages and
message/file exchange between the enterprise and the remittance
network member.
[0032] One embodiment of the invention provides the following
privacy and disclosure features. An enhanced account statement to
show current information plus some additional disclosures
pertaining to the calculation of the spread for each transaction. A
debit from KX account is shown on account statement. In
account-to-anything products, disclosures for account-based
products are added to a consumer account agreement booklet and the
consumer account fee and information schedule. Disclosures can be
available in English and Spanish, for example. Annual privacy
policy can be distributed in accordance with requirements for all
types of accounts. For anything-to-anything at remittance, a
disclosure, referred to herein as an information confirmation, is
signed by the remitter, for each individual remittance, printed in
both English and the customer's preferred language as indicated in
an associated system. For cash-to-anything at enrollment, a new
service agreement form at enrollment is provided for privacy/terms
and conditions, available in English and in the customer's
preferred language, as a separate enclosure provided to the
remitter at the time of enrollment. In one embodiment of the
invention, the form is signed by customer and retention is stored
in centralized storage. A privacy policy can be sent annually to
any remitter with an active status on his or her record. The
invention identifies and provides a file of all active cash based
remittance accounts. One embodiment of the invention integrates
relevant disclosure reporting capability from a preexisting dynamic
disclosure service. In one embodiment of the invention, each global
remittance transaction prints the following documents: "Transaction
disclosure" for verification and signatures and "Transaction
Record" at the conclusion of the transaction.
[0033] One embodiment of the invention provides a KX remittance
account and associated features and functionality as follows:
An Exemplary Remittance Account
[0034] A KX Account is an on demand remittance DDA account with the
ability to have one or multiple beneficiaries. Following is a list
of features that are by way of example only and are not meant to be
limiting.
Features:
[0035] Sales Channels SVP, EDGE system, i.e. existing customers,
Internet banking, i.e. existing customers. [0036] KX account to
have the ability to send money on demand at any time during the
day, e.g. up to 8:00 pm PST, to partner bank beneficiary or send
regular, recurring scheduled payments, or ad hoc payments. [0037]
Funds are hard memo posted to lock in funds for transfer in the
future. Remitter cannot withdraw these funds after authorizing a
funds transfer. [0038] Set up an on demand remittance DDA Account
with the ability to have single or multiple beneficiaries. [0039]
Ability to send money real time through message base transfer.
[0040] Ability to designate a future date and amount for
remittance. [0041] Ability to transfer funds into the KX account.
[0042] No ability to write checks on the account. [0043] No
accounts or credit cards can be linked to the account to provide or
receive overdraft protection. [0044] Ability to place a memo hold
on funds for the amount of transaction plus fees. Does not apply if
posted real time. [0045] Ability for the existing customer to
attach KX account to their existing ATM card. [0046] Account
monthly statement to have all the same required fields as KF
statement. [0047] All options need to be set up and subject to
established aggregate remittance limits. [0048] The requirements
for the type of currency a beneficiary can receive and limitations
on the transfer amounts are predetermined. [0049] The business
group to provide the fee structure including pricing and promotion
as provided by the product pricing catalog. [0050] The business to
provide appropriate materials for disclosures and Welcome kit.
[0051] The remitter is also given the option how he/she wants the
beneficiary to receive the funds. The following four options are
given. One or more of the following options can be selected:
[0052] KX Account to Account--Ability to send money at any time
during the day to partner bank beneficiary account or send
regularly scheduled payments to beneficiary account. Multiple
beneficiaries can be set up on KX account. Can use sales channels,
e.g. SVP, Edge (existing customers) and Internet banking (existing
customers) and a universal workstation (UW) for cross border
servicing.
[0053] KX Account to Cash--Ability to send money at any time during
the day to partner bank for cash pick up. Multiple beneficiaries
can be set up on KX account to receive cash. Can use sales channels
such as SVP, Edge (Existing customers) and Internet Banking
(Existing customers), and UW.
[0054] KX Account to Instrument--Ability to send money at any time
during the day to partner bank for payment via negotiable
instrument, such as, demand draft delivery. Multiple beneficiaries
can be set up on KX account to receive negotiable instruments. Can
use sales channels such as, Edge (existing customers) Internet
Banking (Existing customers) and UW.
[0055] KX Account to Card--Ability to send money at any time during
the day to the partner bank to be given to the beneficiary in the
form of some prepaid, i.e. stored value, card issued by the partner
bank. It should be appreciated that this does not include ATM.
Multiple beneficiaries can be set up on KX account to receive
cards. Use sales channels such as SVP, Edge (existing customers)
Internet Banking (Existing customers) and UW.
Exemplary Messages
[0056] One embodiment of the invention provides for one or more
ways to communicate with a partner bank, also referred to herein as
a remittance network member. It should be appreciated that a
request can be delivered to the partner bank via enterprise
internal and proprietary messaging, SFT, Swift or phone call. A
primary and secondary delivery method can be defined for each
partner bank. This message can be delivered synchronously (sync) or
asynchronously (async) depending on the delivery method: [0057]
Proprietary--Sync; [0058] SFT--Async; and [0059] Swift--Async.
[0060] In one embodiment of the invention, such message is able to
support single account verification or a list of accounts.
Seven Exemplary Processes
[0061] One embodiment of the invention can be described with
respect to seven processes, by is by no means limited to seven,
referred to herein as: cash-to-cash transfer, remittance
account-to-cash transfer, cash-to-account transfer, account-to-cash
set-up process, cash-to-account set-up process, phone bank
remittance account set-up, and phone bank remittance account
transfer. It should be appreciated that a final process, referred
to herein as clear-to-pay by an international remittance engine can
be considered an eighth process. The details of each process
according to an embodiment of the invention are described
hereinbelow.
[0062] It should be appreciated that the terms, system and process,
are used hereinbelow interchangeably for ease of understanding the
inventive concept within context.
An Exemplary Store Vision Teller (SVT) Cash-to-Cash Transfer
Process
[0063] One embodiment of the invention is described with respect to
the following scenario and can described with reference to FIG. 3.
The following scenario is meant by way of example only for ease of
understanding and is not meant to be limiting.
Triggering Event(s)
[0064] In one embodiment of the invention, a person walks into
retail store that uses a Store Vision Teller (SVT) and requests a
cash-to-cash transfer. It should be appreciated that the customer
is not doing a wire transfer.
Process Flow
[0065] A customer requests a cash-to-cash transfer 1.1.
[0066] The teller supported by the SVT, or simply, SVT determines
qualifications for transfer 1.2. Example data are as follows:
[0067] Is this a global remittance customer? [0068] What is
recipient country? [0069] Address of beneficiary. [0070]
Identification verification. [0071] Amount to be transferred?
[0072] Currency of transfer. [0073] Any applicable discounts
including promotional code.
[0074] SVT determines if this a cash-to-cash transfer 1.3.
[0075] If not, then the customer is referred to other transfer
processes and the SVT cash-to-cash process ends.
[0076] If yes, then SVT captures the amount of transaction and use
a currency calculator 1.4.
[0077] SVT determines the exchange rate and communicates this to
customer, as well as the transfer amount and fee 1.5.
[0078] SVT tells the customer what they need to provide in US
dollars to cover the transfer amount and fee 1.6
[0079] Is addition, SVT discloses the amount earned by the
enterprise on the exchange to the customer 1.7
[0080] It should be appreciated that according to one embodiment of
the invention, the following steps (1.8 through 1.10) are
considered as part of an enrollment process, and wherein a
relationship is established between remitter and beneficiaries as
follows:
[0081] SVT retrieves or sets up transactional profiles for this
remitter 1.8. Example information are as follows: [0082] Sender
profile; and [0083] Beneficiary profile(s).
[0084] SVT confirms or overrides the transaction profile for
remitter 1.9. Example related information are as follows: [0085]
Sender name; [0086] Sender address; [0087] Sender phone; [0088]
Confirm sender identification, e.g. using two forms of
identification previously stored in SVT; [0089] Sender social
security number (SSN) (optional); and [0090] ECN is generated when
the profile is created.
[0091] SVT creates or overrides the transaction profile for
beneficiary 1.10. Example related information are as follows:
[0092] Beneficiary name; [0093] Beneficiary address; [0094]
Beneficiary phone (optional); [0095] Beneficiary bank and country
code, i.e. where the beneficiary will access the funds. Such bank
and code can be available from a drop down list.
[0096] The teller validates information captured with customer,
e.g. verbal 1.11. In one embodiment of the invention, the SVT
system prompts the teller to capture such information from the
customer.
[0097] SVT sends the transaction information to one or more
subsystems for validation to precede forward 1.12.
[0098] SVT determines if it is OK to follow through with
transaction 1.13. If not, then SVT determines whether to exit
transaction or override 1.14. If the decision is to exit the
transaction, then the SVT cash-to-cash process ends.
[0099] If the decision is to override, then control goes to SVT
producing a confirmation number for the customer 1.15. Example
information are as follows: [0100] Dollar amount of the transfer;
[0101] Exchange rate; and [0102] Fee.
[0103] If SVT determines if it is OK to follow through with
transaction 1.13, then control goes to SVT producing a confirmation
number for the customer 1.15 as hereinabove.
[0104] The customer validates the confirmation 1.16.
[0105] The customer determines if it is OK to do transaction 1.17.
If not, then the customer uses SVT to alter the transaction
customer 1.18. Control may return to any previous point in the
transaction to edit information 1.19. It should be appreciated that
in one embodiment of the invention, SVT allows transaction editing.
In another embodiment of the invention, SVT exits the transaction
process and starts a new transaction.
[0106] If the customer determines if it is OK to do transaction
1.17, then the customer signs a confirmation and provides the cash
and signed form to teller 1.20.
[0107] The teller, via SVT performs a teller "cash-in" process and
creates a general ledger (GL) ticket 1.21. The teller collects the
amount to be transferred and the fee.
[0108] SVT transfers the information to an international remittance
engine (IRE) for processing 1.22.
[0109] The IRE receives the cash-to-cash transfer information
1.23.
[0110] The International system creates a confirmation number for
transaction 1.24. The international system stores the transactional
information for future processing as well as any other system
stores the transactional information.
[0111] The SVT prints a final receipt for the customer 1.25. By way
of example, the final receipt may show the following, but is by no
means limited to: [0112] Dollar amount of the transfer; [0113]
Exchange rate; [0114] Fee; [0115] SVT transaction number; [0116]
Confirmation number; and [0117] Customer number.
[0118] The disclosure(s), including the receipt, is provided to the
customer 1.26. This is an opportunity for the enterprise or partner
to provide other types of information for the customer. In one
embodiment of the invention, the enterprise complies with
regulations and provides regulatory disclosure, such as for
example, the amount of profit to the enterprise for this particular
remittance transaction.
[0119] In possession of the receipt and other disclosures, the
customer is able to leave the vicinity of the SVT, such as a retail
store 1.27.
[0120] According to one embodiment of the invention, the system
inquires if the person performing the remittance is a first-time
remitter 1.28. If not, the SVT cash-to-cash process ends. If yes,
the system sends a trigger, by way of example, actual membership
information, to a second system or process that then produces and
sends a membership packet to the customer 1.29. In one embodiment
of the invention, the customer is sent a card. The SVT cash-to-cash
process ends.
Outputs
[0121] Following are some example outputs according to one or more
embodiments of the invention. Such list is by no means exhaustive:
[0122] An enterprise customer number is assigned and links to the
beneficiary from the remitter are created. [0123] A sales tracking
system has set-up information. [0124] Compliance information has
been recorded. [0125] The cash-to-cash global remittance
transaction is stored in SVT. [0126] A transaction profile(s) is
stored in the SVT. [0127] Data is transferred to the International
Remittance Engine for the creation of a confirmation number. [0128]
The transaction data are stored in the International Remittance
Engine for the purposes of further processing. [0129] The
transaction data are sent to the appropriate systems, for example,
to create the membership packet for the customer.
An Exemplary Store Vision Teller (SVT) Cash-to-Account Transfer
Process
[0130] One embodiment of the invention is described with respect to
the following scenario and can be described with reference to FIG.
4. The following scenario is meant by way of example only for ease
of understanding and is not meant to be limiting.
Triggering Event(s)
[0131] An example triggering event is a person walking into a
retail store which uses an SVT system and process and requests a
cash-to-account transfer.
[0132] Or, another example of a triggering event is a customer has
previously been set up on cash-to-account processing.
Process Flow
[0133] One embodiment of the invention can be described as follows.
The described process is meant by way of example and is not meant
to be exhaustive.
[0134] A customer requests a cash-to-account transfer 2.1.
[0135] SVT determines the qualifications for the transfer 2.2.
Example of information acquired or determined by SVT are as
follows: [0136] Is this a Global Remittance customer? [0137] What
is the recipient country? [0138] What is the address of the
beneficiary? [0139] Confirm that the beneficiary has an account at
a partner bank. [0140] Perform identification verification. [0141]
What is the amount to be transferred? [0142] What is the currency
of the transfer? [0143] Should any discounts be applied, such as
from a promotional code?
[0144] SVT determines if a cash-to-account transfer is possible
2.3. If not, SVT refers the customer to the cash-to-cash transfer
2.4. Then, SVT determines if the customer wants the cash-to-cash
transfer 2.5. If yes, the customer is referred to the cash-to-cash
transfer process. Otherwise, SVT ends the cash-to-account
process.
[0145] If the customer wants a cash-to-cash transfer, then SVT asks
the customer if the customer wants to get set up for
cash-to-account. SVT sends the customer to a store banker to get
set up for cash-to-account 2.6 the details of which are described
hereinbelow.
[0146] If SVT determines a cash-to-account transfer is possible
2.3, SVT then captures the amount of transaction and uses a
currency calculator 2.7. SVT determines an exchange rate and
communicates this to the customer, specifically, as the transfer
amount and fee 2.8. It should be appreciated that how SVT obtains
and assigns the foreign exchange (FX) rate can be by any means. SVT
discloses the amount earned by the enterprise, such as Wells Fargo
for example, on the exchange, such as a receipt or disclosure, to
the customer 2.10. In one embodiment of the invention, the
enterprise complies with regulations and provides regulatory
disclosure, such as for example, the amount of profit to the
enterprise for this particular remittance transaction.
Additionally, SVT tells the customer what they need to provide in
US dollars to cover the transfer amount and the fee 2.9. That is,
SVT retrieves transactional profiles for the remitter 2.11.
Examples of such information include: [0147] Sender profile; and
[0148] Beneficiary profile(s).
[0149] SVT confirms/overrides information in the transaction
profile for the remitter 2.12. Examples of such information
include: [0150] Sender name; [0151] Sender address; [0152] Sender
phone; [0153] Confirms sender identification, e.g. SVT stores two
forms of identification); and [0154] Sender SSN (optional).
[0155] SVT confirms/overrides information in the transaction
profile for the beneficiary 2.13. Examples of such information
include: [0156] Beneficiary name; [0157] Beneficiary address;
[0158] Beneficiary phone (optional); [0159] Beneficiary bank and
country code, i.e. where the beneficiary will access funds, which
can be picked from a drop down list; [0160] Beneficiary bank
account number; and [0161] Status of bank account validation, i.e.
indicates that the account is valid.
[0162] Teller verifies whether the KX account is active with a
verified beneficiary on record 2.14. If not, Teller determines if
the customer wants to proceed with a cash-to-cash transfer. If yes,
control is transferred to the cash-to-cash transfer process. If
not, SVT sends the customer to the banker to re-set beneficiary
account information 2.16 and the customer is directed to the SVP
Cash-to-account set up process described hereinbelow.
[0163] If the Teller verifies whether the KX account is active with
a verified beneficiary on record 2.14, then the teller validates
the information captured with the customer, for example, verbally
2.17. In one embodiment of the invention, the system prompts the
teller to validate the information.
[0164] SVT sends transaction information to various one or more
sub-systems for validation to proceed 2.18.
[0165] SVT determines if it is okay to follow through with the
transaction 2.19. If not okay to proceed, SVT determines whether to
exit the transaction or override the decision 2.20. If the decision
is to exit, then SVT ends the cash-to-account process. If the
decision is overridden, then SVT proceeds to produce a confirmation
for the customer 2.21. In one embodiment of the invention, two
copies of the confirmation acknowledgement contains: [0166] Dollar
amount of transfer; [0167] Exchange rate; and [0168] Fee.
[0169] As well, if SVT determines to proceed with the transaction,
SVT proceeds to produce a confirmation for the customer 2.21.
[0170] The customer validates the confirmation 2.22.
[0171] The customer determines whether or not to follow through
with the transaction 2.23. If the customer does not follow through
with the transaction, the customer can alter the transaction by way
of the SVT 2.24. As well, the customer via SVT can return to any
previous point in the transaction to edit information 2.25. In one
embodiment of the invention, SVT cancels the current transaction
and generates a new transaction for the new and/or changed
information.
[0172] If the customer decides to proceed with the transaction, the
customer signs the confirmation and provides the cash and signed
form to a teller 2.26. SVT then performs a teller cash-in process
and creates a GL ticket 2.27. By way of example, the following
information is provided to the SVT: [0173] Collected amount to be
transferred and fee; [0174] Existing process; and [0175] Cash-in
process can be electronic. [0176] SVT transfers information to the
IRE for processing 2.28. [0177] IRE receives cash-to-account
transaction information 2.29 and generates a confirmation number
for the transaction 2.30. SVT may store such transaction
information and any other systems as well may store such
transaction information for future reference 2.30.
[0178] SVT prints a final receipt for the customer 2.31. Example
information provided on the receipt include, but are not limited
to: [0179] Dollar amount of transfer; [0180] Exchange rate; [0181]
Fee; [0182] SVT transaction number; [0183] Confirmation number; and
[0184] Customer or member number.
[0185] SVT provides other disclosure, if available, to the customer
2.32.
[0186] The customer, in possession of receipt and any other
disclosure, is in a position to leave the retail store 2.33.
[0187] The SVT cash-to-account process ends.
Outputs
[0188] Following are some example outputs according to one or more
embodiments of the invention. Such list is by no means exhaustive:
[0189] Compliance information has been records; [0190]
Cash-to-account Global Remittance Transaction in SVT; [0191]
Transaction Profile(s) in SVT; [0192] Data transferred to IRE for
creation of confirmation number; and [0193] Transaction in IRE for
further processing.
An Exemplary Store Vision Teller (SVT) Remittance-Account-to-Cash
Transfer Process
[0194] One embodiment of the invention is described with respect to
the following scenario and can be described with reference to FIG.
5. The following scenario is meant by way of example only for ease
of understanding and is not meant to be limiting.
Triggering Event(s)
[0195] According to one embodiment of the invention, an account
holder, such as one at Wells Fargo, for example, uses the
remittance system such as in a retail store, for example, and
requests an account-to-cash transfer.
[0196] In one embodiment of the invention, an enterprise customer,
such as a Wells Fargo customer, has previously been set up with a
remittance account, an on-demand remittance DDA account with
ability to have one or multiple beneficiaries, referred to herein
as a KX account.
Process Flow
[0197] A customer requests a KX-account-to-cash transfer 3.1 by way
of the SVT.
[0198] The SVT system and process determines qualifications for
such transfer 3.2.
[0199] For example, the system may perform the actions as follows
or prompt as follows to gather more information: [0200] Is the
customer is a global remittance customer? [0201] Does the customer
have a valid enterprise KX remittance account? [0202] What is the
recipient country? [0203] What is the address of the beneficiary?p1
Identification verification. [0204] What is the amount to be
transferred?
[0205] The system determines if a KX-account-to-cash transfer can
be performed 3.3.
[0206] If no, then the system refers the customer to the
cash-to-cash transfer process 3.4. The system determines if the
customer want a cash-to-cash transfer 3.4, as well as if the
customer wants to set up an account for cash-to-account transfer
3.5. If the customer wants to set up an account for cash-to-account
transfer, then the customer is sent to a store banker to set up an
account-to-cash account 3.6. The customer is referred to the SVP
Account-to-cash set up process described hereinbelow.
[0207] If yes, the customer wants a cash-to-cash transfer, then the
customer is directed to the cash-to-cash transfer process described
hereinabove. If not, then the SVT account-to-cash process ends.
[0208] If yes, the customer wants a KX-account-to-cash transfer as
in 3.3, then the system captures the amount of the transaction and
the type of currency requests 3.7.
[0209] The exchange rate is determined and communicated to the
customer. Other information, such as the transfer amount and the
fee can also be communicated to the customer 3.8.
[0210] The system informs the customer the amount of source
dollars, for example, US dollars, to cover the transfer amount and
fee 3.9. The amount earned by the enterprise on such exchange is
disclosed to the customer 3.10.
[0211] SVT posts a debit memo to the KX-account 3.11. SVT
determines if sufficient funds are available 3.12. If not, SVT
determines whether to override and continue the transaction or to
exit the transaction 3.13. If the decision is exit the transaction,
then the SVT account-to-cash process ends 3.131. If the decision is
to override and continue the transaction, the control of the SVT
system and process goes to the step where the teller validates the
information captured with the actual customer, verbally, for
example 3.17. If it is determined that enough funds are available
3.12, then control also goes to the step where the teller validates
the information captured with the actual customer, verbally, for
example 3.17.
[0212] In addition to the logical flow described hereinabove
starting with posting a debit memo, SVT also retrieves
transactional profiles for the remitter 3.14. Following are
examples of the type of information gathered: [0213] Sender
profile; and [0214] Beneficiary profile(s), for example, up to five
beneficiaries.
[0215] SVT confirms or overrides the transaction profile for the
remitter 3.15. By way of example, elements of the transactional
profile include: [0216] Sender name; [0217] Sender address; [0218]
Sender phone; [0219] Sender identification , for example, two forms
of identification; and [0220] Sender Social Security Number (SSN)
(optional).
[0221] Then, SVT confirms/overrides the transactional profile for
the beneficiary 3.16. By way of example, elements of such
transactional profile include: [0222] Beneficiary name; [0223]
Beneficiary address; [0224] Beneficiary phone (optional); and
[0225] Beneficiary bank and country code, i.e. where they access
the funds, for example, they can pick from a drop down list.
[0226] The teller validates the information captured at this point
with the actual customer, for example, verbally 3.17. In one
embodiment of the invention, the system prompts for such
validation.
[0227] SVT then sends the transaction information to one or more
systems for validation to proceed forward 3.18. If it is not okay
to proceed with the transaction 3.19, then SVT determines whether
to exit the transaction or to override and proceed 3.20. If the
determination is to exit, then the SVT account-to-cash process
ends. If the determination is to override, then control goes to the
step of producing a confirmation for the customer 3.21. Example
information produced for the confirmation is as follows: [0228]
Dollar amount of the transfer; [0229] Exchange rate; and [0230]
Fee.
[0231] The confirmation information is validated 3.22.
[0232] SVT determines whether or not to proceed with or perform the
transaction 3.23. If not, the customer can alter the transaction as
per customer request 3.24, and the customer can return to any
previous point in the transaction to edit the information 3.25. It
should be appreciated that in another embodiment of the invention,
SVT exits the present transaction and begins a new transaction.
[0233] If yes, it is okay to proceed with the transaction, the
customer signs the confirmation and provides the signed form to the
teller 3.26.
[0234] SVT creates a GL-ticket 3.27. It should be appreciated that
a GL-offset is created.
[0235] The information gathered is transferred to an international
remittance engine (IRE) for processing 3.28. Such engine can be
third party.
[0236] The IRE receives the account-to-cash transfer information
3.29. An international system generates a confirmation number for
the transaction 3.30. The international system stores such
transaction information on its one or more sub-systems. Any other
sub-system may store such transaction information if desired.
[0237] SVT prints a final receipt for the customer 3.31. By way of
example, the receipt contains certain types of information as
follows: [0238] Dollar amount of transfer; [0239] Exchange rate;
[0240] Fee; [0241] SVT transaction number; [0242] Confirmation
number; and [0243] Customer or member number.
[0244] SVT gives such disclosure, i.e. the receipt, to the customer
3.32. In one embodiment of the invention, the enterprise complies
with regulations and provides regulatory disclosure, such as for
example, the amount of profit to the enterprise for this particular
remittance transaction. It should be appreciated that the
information disclosed for each transaction can be predetermined
according to particular embodiments of the invention and the
specific information described hereinabove is not meant to be
exclusive.
[0245] The customer, having received the receipt and other
disclosures, is able to leave the SVT, such as a retail store, if
the SVT is in such store 3.33.
[0246] The SVT cash-to-account process ends.
Outputs
[0247] Following are some example outputs according to one or more
embodiments of the invention. Such list is by no means exhaustive:
[0248] Compliance information has been recorded. [0249] Control can
go to SVT's Account-to-Cash Global Remittance Transaction process.
[0250] Transaction profile(s) in SVT. [0251] Data transferred to
IRE for creation of confirmation number. [0252] Transaction is sent
to IRE for further processing.
An Exemplary Store Vision Platform (SVP) Remittance-Account-to-Cash
Set-up Process
[0253] One embodiment of the invention is described with respect to
the following scenario and can be described with reference to FIG.
6. The following scenario is meant by way of example only for ease
of understanding and is not meant to be limiting.
Triggering Event(s)
[0254] In one embodiment of the invention, a triggering event can
be described as an enterprise account holder entering an
environment, such as a retail store, that uses SVT. The account
holder requests an account-to-cash transfer.
Assumption(s):
[0255] According to an embodiment of the invention any of the
follow can be assumed: [0256] The enterprise will set up an
enterprise remittance account from which funds can be accessed for
transfer. [0257] An SVP entity, such as a banker, performs the
set-up. [0258] An SVT entity, such as a teller, performs the actual
transaction.
Process Flow
[0259] A customer requests a remittance account-to-cash transfer
4.1.
[0260] An enterprise entity, which for ease of understanding is
referred to herein as banker, authenticates the customer 4.2.
[0261] The banker captures sender and beneficiary information 4.3.
by way of example, captured information is provided as follows:
[0262] Uses SVP enrollment screen; [0263] Sender profile
information; [0264] Beneficiary profile information; and [0265]
Fill out signature cards.
[0266] The banker deposits the amount into the remittance account
4.4. In one embodiment of the invention, the banker takes cash to
the teller line to get a deposit receipt. The banker executes the
transaction using the teller as needed 4.6 and control goes to the
SVT account-to-cash process described hereinabove.
[0267] In addition, the banker sends membership information to one
or more various internal systems that produce and send a membership
packet to the customer 4.5. In one embodiment of the invention, the
customer is sent a card. The SVP account-to-cash set-up process
ends.
An Exemplary Store Vision Platform (SVP) Cash-to-Account Set-up
Process
[0268] One embodiment of the invention is described with respect to
the following scenario and can be described with reference to FIG.
7. The following scenario is meant by way of example only for ease
of understanding and is not meant to be limiting.
Triggering Event(s)
[0269] In one embodiment of the invention, a triggering event can
be described as an enterprise account holder entering an
environment, such as a retail store, that uses SVT. The account
holder requests a cash-to-account transfer.
Assumption(s):
[0270] According to an embodiment of the invention any of the
follow can be assumed: [0271] The enterprise entity, referred to
herein as a banker, verifies beneficiary account with a partner
bank. [0272] The status of validation is kept on the SVT
beneficiary profile. [0273] The SVP banker performs the set-up
process. [0274] The teller on SVT performs the transfer
transaction.
Process Flow
[0275] A customer requests a cash-to-account transfer 5.1.
[0276] The banker sets up a customer profile, containing sender
profile and beneficiary profile information 5.2.
[0277] In one embodiment of the invention, the enterprise can
attempt to cross-sell and/or set up an enterprise account for the
customer 5.3.
[0278] The system initiates and sends a message to the partner bank
to validate the beneficiary account information 5.4, where the
message includes the beneficiary account information.
[0279] The system receives a message regarding validation of the
beneficiary account and sets a status indicator 5.5. For example,
the status indicator can reflect: account OK or account not OK.
[0280] The set-up process initiates executing the transaction by
way of using the teller 5.7. Control then goes to the SVT
cash-to-account process described hereinabove.
[0281] In addition, the banker sends membership information to one
or more various internal systems that produce and send a membership
packet to the customer 5.6. In one embodiment of the invention, the
customer is sent a card. The SVP cash-to-account set-up process
ends.
An Exemplary Phone Bank Remittance Account Set-up Process
[0282] One embodiment of the invention is described with respect to
the following scenario and can be described with reference to FIG.
8. The following scenario is meant by way of example only for ease
of understanding and is not meant to be limiting.
Triggering Event(s)
[0283] A triggering event is an enterprise customer calling a
predetermined number, such as an 800 number, to establish a new
remittance account.
Constraint(s):
[0284] If the customer is an non-resident alien (NRA) customer who
does not have social security as well as no existing relationship
with the enterprise, the customer is referred to go into an actual
store.
Assumption(s):
[0285] A host system update process can take from one to three
business days.
Process Flow
[0286] A customer requests a remittance account, also referred to
herein as a KX remittance account, 6.1 over the phone.
[0287] An individual or representative in the enterprise's phone
bank sales department or the like authenticate the customer 6.2.
For example, the representative can perform the following: [0288]
Set-up or verify the customer's profile. [0289] Perform risk
screening on new customers. [0290] Verify customer's name and
address via an internal system or third party system, such as
CheckPoint.
[0291] The representative determines the type of transfer(s) the
customer desires 6.3. Examples of types of transfers are as
follows: [0292] Account-to-cash; [0293] Account-to-account; [0294]
Account-to-prepaid card; and [0295] Account to instrument.
[0296] The representative captures appropriate information to
support the transfer type(s) selected 6.4. By way of example, some
information captured is as follows: [0297] Specific data elements
by transfer type. [0298] Customer can select one or more transfer
option. [0299] The remittance account title is limited to
INDIVIDUAL.
[0300] The representative captures beneficiary information 6.5.
Some embodiment of further processing is as follows: [0301] The
representative uses the appropriate remittance screen in a
subsystem used by the representative. [0302] The beneficiary
information is sent to a fulfillment group to be host updated to
CIS, a subsystem. [0303] One or more beneficiaries can be set-up.
[0304] Print signature card for remitter and provide it to the
remitter, such as for example, by mail. [0305] No minimum opening
balance is required. [0306] Funding optional. [0307] The KX
remittance account can be linked to any new or existing card.
[0308] The representative sends a welcome letter to the remitter
6.6 and the business communication process proceeds as usual. It
should be appreciated that in one embodiment of the invention, the
phone bank sends the letter whereas the card, if ordered, is sent
by the appropriate subsystem or third party vendor.
[0309] Control is then passed for proceeding with a transaction to
the SVT account-to-cash process 6.7 described herein. In one
embodiment of the invention the customer completes the first
transaction at the store because a signed disclosed documentation
is required.
An Exemplary Phone Bank Remittance Account Transfer Process
[0310] One embodiment of the invention is described with respect to
the following scenario and can be described with reference to FIG.
9. The following scenario is meant by way of example only for ease
of understanding and is not meant to be limiting.
Triggering Event(s)
[0311] An enterprise customer calls into a predetermined number,
such as an 800 number. The customer has been previously set up with
a KX account for remittance.
Assumption(s)
[0312] The remitter has completed a face-to-face transaction in the
store. This only applies to the first transaction. Subsequent
transactions can be done via phone or other designated channels
when available in the future.
[0313] The banker/system can systematically validate that the first
transaction took place.
[0314] Any transfers requested after a predetermined time, such as
for example, 8 pm are processed the next business day.
Process Flow
[0315] A customer requests a KX-account transfer 7.1.
[0316] The enterprise banker or system determines the
qualifications for the transfer 7.2. Examples of such
qualifications are as follows: [0317] Does the customer have a
valid enterprise KX remittance account? [0318] The customer selects
a designated recipient country and bank recipient. [0319] The
system or banker validates the address of the beneficiary and any
additions or changes are referred to the store. [0320] Verify
identification. [0321] Determine amount to be transferred. [0322]
Any discounts to be applied, including promotional codes?
[0323] In one embodiment of the invention, the phone bank reads the
beneficiary profile information.
[0324] In one embodiment of the invention the platform
automatically prevents more than a maximum amount, for example,
$3000, transfer to a single beneficiary in a single day.
[0325] The banker determines if all the necessary information is
gathered, based on the type of transfer 7.3. For example, if it is
an account-to-cash transfer, a determination of has the transaction
indicator been set to show a first transaction has taken place in
the store? Another example is for an account-to-account transfer,
has the beneficiary account been verified?
[0326] If not, the banker refers the customer to the store 7.4 and
the store proceeds further processing.
[0327] If yes, the banker captures the amount of the transaction
and uses a currency calculator 7.5.
[0328] The banker determines the exchange rate and communicates
this as well as the transfer amount and the fee to the customer
7.6.
[0329] The banker informs the customer what the customer needs to
provide in US dollars to cover the transfer amount and the fee 7.7.
As well, the banker discloses the amount earned by the enterprise
on the exchange to the customer 7.8.
[0330] The phone banker requests a debit memo post to the
KX-account, which credits remittance to GL and fee account
automatically 7.9.
[0331] The phone banker determines if funds are available 7.10.
[0332] If not, control is passed to an existing funds transfer
process. That is, the customer must transfer funds via existing
funds transfer guidelines or be referred to the store.
[0333] If yes, then a confirmation script is provided to, such as
read to, the customer for permission to proceed 7.11. Examples of
what the script contains is as follows: [0334] Dollar amount of
transfer; [0335] Exchange rate; [0336] Fee; and [0337] Spread.
[0338] In one embodiment of the invention, information from the
transaction appears on a financial system's monthly statement.
[0339] The customer validates the confirmation, for example,
verbally 7.12.
[0340] The customer determines if it is okay to proceed with the
transaction 7.13. If not, then the phone banker alters the
transaction as requested by the customer 7.14. Control may return
to any previous point in the transaction process to edit the
information 7.15.
[0341] If yes, then the transaction process continues 7.16 for
completion. The phone banker sends transfer information to the
International Remittance Engine (IRE) for processing 7.17.
[0342] The IRE receives the transfer information 7.18 and the
international system generates a confirmation number for the
transaction 7.19. It should be appreciated that the international
system stores the transaction as well as any other subsystem stores
the transaction for further reference.
[0343] The IRE sends the confirmation number to the phone banker to
for display 7.20. It should be appreciated that there are other
confirmation numbers used as reference numbers for other enterprise
systems and subsystems as necessary or when desired.
[0344] The phone banker provides, such as reads, the confirmation
and reference information to the customer 7.21.
[0345] The customer, having the confirmation and reference numbers
can hang up the phone. The phone bank cash-to-account process
ends.
Outputs
[0346] Following are some example outputs according to one or more
embodiments of the invention. Such list is by no means exhaustive:
[0347] Compliance information has been communicated to the
customer. [0348] The customer has verbally received the applicable
confirmation and reference numbers. [0349] Data is transferred to
the IRE for creation of the confirmation number. [0350] Transaction
in stored in the IRE for further processing. [0351] Transaction
data appear on monthly KX account statements.
[0352] One embodiment of the invention can be described with
reference to FIG. 10, a schematic diagram showing the main
components of the invention. In particular, SVP 1102 system
performs customer and beneficiary set up. SVT 1004 performs
anything to anything transactions. Business services 1006 provides
enrollment set up, request status, verification process, and other
related functions as shown. Business services 1008 for SVT provides
request/status, retrieve customer and beneficiary information,
record contract information, transaction account, FX calculation,
generate confirmation number, calculate fees, and the like as
shown. The IRE 1010 performs the many functions as shown, e.g.
determine transaction method, apply FX rate, create FX deal input
file, maintain list of banks, and the like as shown. A product
catalogue 1012 is maintained and linked to the SVT business
services 1008. Remittance messages are sent to the enterprise bank
1018 using XML 1014. Real time messages 1016 are sent to and
received from the enterprise bank 1018. A deal subsystem 1020
provides ability for automatic FX Deal creation based on input from
the IRE.
[0353] Accordingly, although the invention has been described in
detail with reference to particular preferred embodiments, persons
possessing ordinary skill in the art to which this invention
pertains will appreciate that various modifications and
enhancements may be made without departing from the spirit and
scope of the claims that follow.
* * * * *