U.S. patent application number 13/745033 was filed with the patent office on 2013-10-03 for remote deposit capture method and apparatus.
The applicant listed for this patent is CACHET FINANCIAL SOLUTIONS INC.. Invention is credited to Sunil BHUJLE, Christopher F. EBBERT, Sunny MILENOV, Viktor POTERYAKHIN.
Application Number | 20130259357 13/745033 |
Document ID | / |
Family ID | 49235105 |
Filed Date | 2013-10-03 |
United States Patent
Application |
20130259357 |
Kind Code |
A1 |
EBBERT; Christopher F. ; et
al. |
October 3, 2013 |
REMOTE DEPOSIT CAPTURE METHOD AND APPARATUS
Abstract
A remote deposit capture system is provided that includes the
means for human evaluation of financial transactions, and well as
the application of rules based methodologies.
Inventors: |
EBBERT; Christopher F.;
(Minneapolis, MN) ; BHUJLE; Sunil; (Minneapolis,
MN) ; POTERYAKHIN; Viktor; (Minneapolis, MN) ;
MILENOV; Sunny; (Minneapolis, MN) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
CACHET FINANCIAL SOLUTIONS INC. |
Minneapolis |
MN |
US |
|
|
Family ID: |
49235105 |
Appl. No.: |
13/745033 |
Filed: |
January 18, 2013 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61587748 |
Jan 18, 2012 |
|
|
|
Current U.S.
Class: |
382/137 |
Current CPC
Class: |
G06K 9/00442 20130101;
G06Q 20/32 20130101; G06Q 20/042 20130101 |
Class at
Publication: |
382/137 |
International
Class: |
G06K 9/00 20060101
G06K009/00 |
Claims
1. A remote deposit capture method, the method being performed by
execution of computer readable program code by at least one
processor of at least one computer, the method comprising the steps
of: capturing an image of a financial instrument; interpreting the
image to extract information from the image; applying at least one
rule to the information or image to determine whether to process a
transaction based on the financial instrument.
2. The method of claim I further comprising the step of presenting
the image of the financial instrument for human review.
3. The method of claim 1 wherein further comprising the step of
screening the image and information for completeness and
accuracy.
4. The method of claim 1 wherein the rule is a geographic rule.
5. The method of claim 1 wherein the rule evaluates whether the
financial instrument has been submitted from a user with
authorization for automatic approval.
6. The method of claim 1 wherein the rule evaluates whether the
financial instrument has been submitted from a user selected for
automatic disapproval.
7. The method of claim 1 wherein the rule evaluates the amount of
the financial instrument against an amount entered by a user.
8. The method of claim 1 wherein the rule evaluates whether the
financial instrument exceeds a predefined maximum.
9. The method of claim 1 wherein the rule evaluates whether the
financial instrument is a duplicate.
10. The method of claim 4 wherein the geographic rule evaluates
whether a geographic location given from a user computing device
matches a location associated with the user.
11. The method of claim 4 wherein the geographic rule evaluates
whether a geographic location given from a user computing device is
a prohibited location.
12. The method of claim 4 wherein the geographic rule evaluates
whether a geographic location is outside a predefined geographic
boundary.
13. The method of claim I further comprising the step of
determining a fee.
14. The method of claim 13 wherein the fee is a flat fee.
15. The method of claim 13 wherein the fee is a percentage fee.
16. The method of claim 13 wherein the fee is combination of a flat
fee and a percentage fee.
17. The method of claim 14 wherein the fee is evaluated against a
maximum set by law.
Description
RELATED APPLICATION
[0001] The present application claims priority to, and incorporates
by reference thereto, U.S. Provisional Patent Application No.
61/587,748 filed on Jan. 18, 2012.
BACKGROUND
[0002] 1. Field of the Invention
[0003] This invention relates to a remote deposit capture method
and apparatus. In particular, the invention relates to a method and
apparatus for remote deposit capture of a financial instrument that
provides for the application of various rules and procedures. Of
course, a person of ordinary skill in the art will understand that
the invention is not necessarily so limited.
[0004] 2. Background of the Invention
[0005] Remote Deposit Capture ("RDC") had been termed one of the
most important developments the banking industry has seen in years.
The Federal Reserve, as well as nearly all of the top banks in the
US, and other important financial institutions have either endorsed
or launched RDC services.
[0006] In general terms, RDC is a service that allows a user to
scan checks or other financial instruments and transmit the scanned
images to a bank for posting and clearing. The basic requirements
for an RDC service currently include a user computing device, an
internet or network connection, a check scanner/digital camera or
mobile device with a camera, and a RDC service provider such as a
bank or a third party provider working with the bank. Financial
instruments, such as checks, are scanned to create a digital image.
This digital image is then transmitted (usually over an encrypted
internet connection) to a RDC processor and are then eventually
cleared for deposit.
[0007] The advantages of RDC are many. For businesses the
advantages include accelerated clearings, improved availability of
banking services, enhanced cash flow, reduced costs, and
consolidation of banking relationships. Similarly, RDC is
beneficial to financial institutions by providing them with reduced
transportation costs, new revenue streams and customers, and
reduced processing and clearing costs. Consumers/users also benefit
because they do not have to physically travel to a financial
institution, and can conduct business with any institution and not
just those located nearby.
[0008] RDC does suffer from significant drawbacks. In particular,
it can be difficult to implement rules and procedures to evaluate a
check and/or to evaluate the person seeking to cash the check since
the person is not presenting the check to a human teller.
[0009] Accordingly, a need exists for a RDC system that overcomes
the difficulties of the prior art by providing a means to apply
human judgment to the process of evaluating financial transactions
conducted through RDC systems.
SUMMARY OF THE INVENTION
[0010] An object of the present invention is to provide a RDC
system that substantially eliminates the problems of the prior art.
These and other objects of the present invention will become
apparent to those skilled in the art upon reference to the
following specification, drawings, and claims. To that end, the
present invention comprises a remote deposit capture system that
provides for the application of various rules and procedures.
BRIEF DESCRIPTION OF DRAWINGS
[0011] FIG. 1 is a system flow chart of the present invention.
[0012] FIG. 2 is a data context chart of the present invention.
[0013] FIG. 3 is a business rules flow chart.
[0014] FIG. 4 is a geolocation flow chart.
[0015] FIG. 5 is a fee capping flow chart.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0016] In the Figures, FIG. 1 shows a flowchart of the system of
the present invention. The system operates between a user, a RDC
provider, and a financial institution. The present invention is
also applicable to financial services providers, such as check
cashers and the like, and the RDC provider can be an independent
entity providing outsourced services to the financial entity, or
the financial entity itself can provide the RDC services. The
process utilizes various hardware and software components, as
described herein, which are distributed between the user, RDC
provider, and the financial institution.
[0017] In the first step of the process, the user having been
provided with or given access to a software application denoted
SelectMobile, initiates a session by logging on to the application
(a log on may not be necessary if the user is coming from a known
source). The application can be distributed to a computing device
at the user's site, or the user can remotely access the application
from a computing device via a network connection, such as the
Internet. The user's computing device can be of any conventional
type that can either directly run the application, or provide
network access to the application. Such devices can include a
desktop computer, a server, a mobile computing device such as a
smart phone, handheld computer, and the like.
[0018] After initiating a session, whereby the user has provided
sufficient indicia of authenticity to access an account, the user
will capture on the computing device a financial instrument which
the user desires the system to process. The capture can be
accomplished with a scanning device, such as a flat bed scanner, a
dedicated check scanner, or by utilizing a digital camera such as
those commonly provided with handheld computing devices and/or
smart phones or one interfaced with a desktop computer. The
financial instrument in most cases would be a check which the user
desires to deposit into a financial account with the financial
institution, but could also be any other type of financial
instrument processed by the financial institution such as a
travelers check, a payment coupon, and the like. After the
financial instrument has been captured, an electronic or digital
image of the instrument is then submitted electronically to the RDC
provider for further processing. The RDC provider receives the
submission and begins processing. The RDC provider utilizes a
combination of software and hardware components generally operating
in the provider's computer environment. The RDC provider's network,
servers, and software are utilized for this purpose.
[0019] The submission data is stored in the RDC provider's database
for data preservation and record keeping purposes.
[0020] The image of the financial instrument is then processed by
the RDC provider. In the case of a check, the processing would
include utilizing character recognition software to capture the
MICR (magnetic ink character recognition) information from the
digital image of the financial instrument such as the account
number of the account the check is written against, name, address,
bank routing information, and check number. MICR processing can
take place on the level of the user's computing device,
particularly if that device is a mobile device, or on the server
level by the RDC provider or financial institution. Additional
information captured from the financial instrument includes
information provided by
[0021] CAR/LAR processing software. CAR/LAR (Courtesy Amount
Recognition/Legal Amount Recognition) provides an automated method
to capture and compare the written value and the numeric value
lines on the financial instrument.
[0022] Next, a determination is made as to whether the check meets
the predefined acceptance criteria used by the system. This
evaluation would include determining if the information captured
during the processing step is accurate, internally consistent, and
valid. If the financial instrument is not acceptable, then the user
is notified and may be provided with an explanation as to the
reason why the instrument was not accepted. The user is then given
the choice to reprocess the instrument, or exit the application.
The user always has the option of taking the financial instrument
directly to a financial institution.
[0023] If the financial instrument is accepted, a submission
received message is transmitted to the user so that the user is
aware that at least initially the financial instrument has been
successfully processed (but not fully accepted). As described
below, additional processing and evaluation must occur before the
financial instrument is finally accepted and deposited by the
financial institution. The system cannot complete the transaction
without the additional verification steps as described below.
[0024] After the submission received message is sent to the user,
the system then generates a submission web page, which is then sent
to the financial institutions computer processing system. This
message can be sent via a computer network such as the Internet,
through a local or intranet system, or it can be sent by a
messaging system such as email or instant messaging.
[0025] At this point, processing is transferred to the financial
institutions computer processing system. The notification sent from
the RDC Processor is received by the financial institution. This
notice would include all the information necessary for the
financial institution to process and evaluate the financial
instrument, including, the account number, routing number, check
number, amount of the check, as well as the digital image of the
front and back of the check/financial instrument. The notification
may include information about multiple transactions for the user
being processed at the same time, past history of user
transactions, account status, or other information. As stated
above, the information can be passed to the financial institution
in various manners. For example, the notification can be posted to
a web page monitored by the financial institution, sent to an email
account, and the like.
[0026] The information is then forwarded, or accessed, by an
operator at the financial institution. The operator is preferably,
but not necessarily, a human being qualified and trained to
evaluate the financial instrument. The operator has access to all
of the information in the notification, including, the digital
image of the financial instrument. While the system itself includes
evaluations and tests to authenticate, evaluate, and verify the
financial instrument, this may not be the same as allowing a
skilled professional human operator to review the instrument. While
computer systems can be programmed to find and detect
irregularities, human skill, judgment, knowledge, and reasoning is
far superior at finding and detecting irregular, fraudulent, or
suspect transactions.
[0027] Next, the operator will submit an evaluation of the
financial instrument, either approving or rejecting the instrument.
If the instrument is rejected an explanation could be included
indicating the reason for rejection. This information is submitted
to the RDC provider for processing and notice to the user.
[0028] If the transaction is approved by the operator, the RDC
Processor then sends a formal file to the financial institution
that conforms to applicable standards for the transfer exchange of
images of financial instruments between financial institutions,
banks, and/or the Federal Reserve. In the most preferred
embodiment, the information is sent in the X9.37 format. This file
is then received by the financial institution and processed through
its general ledger.
[0029] If the transaction is approved, the RDC provider sends a
message to the user indicating the approval status. If the
financial institution operator does not approve the transaction
then a transaction denied message can be sent to the user through
the RDC provider. FIG. 2 is a system context chart showing
generally the data exchange paths between the user, RDC provider,
and the financial institution. The sequence of processing steps is
described above in reference to FIG. 1.
[0030] Alternative embodiments of the invention is set forth in
FIGS. 3-5. In FIGS. 3-5, generally, the Mobile User/API would
likely take place on the user level shown in FIG. 1, the CFS
Business Rules Web Service would take place on the RDC provider or
the financial institution levels shown in FIG. 1, and the
Reviewer/API would take place on the financial institution level
shown in FIG. 1.
[0031] FIG. 3 shows that the acceptance of a valid check is
dependent evaluation of a plurality of business rules. These rules
include such things as: whether the check is written by a
premier/white-list user (which is validated under any
circumstances); whether the check is written by a black-list user
(which is never validated or is only validated based on separate
approval/review); amount difference (fails validation if the user
entered amount and the system recognized amount are different);
maximum dollar amount per deposit (fails validation if the total
amount in the current deposit is greater than a pre-defined value);
maximum number of checks per deposit (fails validation if the total
quantity of checks in the current deposit is greater than a
pre-defined number over a pre-defined period of time); maximum
dollar amount per day (fails validation if the total amount
(including the current deposit) is greater than a pre-defined
value); maximum number of items per day (fails validation if the
total number of items (including the current deposit) is greater
than a pre-defined value); duplicate check (fails validation if the
current check is a duplicate of a check already processed or being
processed in the system); or geographical location (fails
validation if the location of the deposit is outside of a specified
geographical boundary--where geographical location is determined
based on user input or geolocation data available from the user's
computing device or network). Other similar rules can be included,
and the rules and rule values can be determined by the financial
institution, or based on default settings provided by the RDC
provider.
[0032] Next, the results of the rules check are evaluated and if
any rule fails, indicating that the check will not be validated,
control passes to the determine premier/white-list user. If the
user is a premier or white-list user then control passes to the
"Are all checks reviewed?" box. If the user is not a premier or
white-list user then control passes to the "Are failures reviewed?"
box.
[0033] The "Are all checks reviewed?" box provides an option for
all checks, even those validated under the business rules to
receive additional, and preferably, human review. If the checks are
to be reviewed, the checks are presented for review. If not, an
approved message is sent to the user.
[0034] The "Are failures reviewed?" box provides and option to
review checks that have failed one or more of the business rules.
If the failures are reviewed, the checks are presented for review.
If not, a declined message is sent to the user.
[0035] For checks presented for additional review, an additional
evaluation is done to determine if they should still pass the
review. If the check is passed, an approved message is sent to the
user. If not, a declined message is sent.
[0036] FIG. 4 presents the geographical rule in more particular
detail. The purpose of the rule is to allow a financial institution
to enforce a rule prohibiting validation of transactions that take
place from certain geographic locations. For example, certain
geographic locations may be associated with fraud--and transactions
originating therein can therefore be prohibited, or the system
could seek to verify whether a user is in a location that is
unexpected given the user's stated address--in which case the
transaction could be prohibited.
[0037] The process of acceptance or evaluation of a check based on
geographic location begins by determining whether the geographic
location rule is enabled. If the rule is not enabled processing
control returns to the next step in the process bypassing the
geographic rules step. If the rule is enabled, the process verifies
whether the geographic location of the user is within the
predefined boundaries set by the financial institution. Again, the
institution has a variety of choices on how to determine
boundaries. The rule could be set to not accept any check from a
location outside the United States. They rule could be set to no
accept any check from certain countries, or territories within a
country.
[0038] If the location is outside the boundary, processing returns
to the next step with a flag that the geolocation rule has failed,
which presumably would lead to a process declined message being
sent to the user (subject to other rules described above).
[0039] The location information preferably is based on a
geolocation signal received from the user. For, example from the
user's cell phone, or the geolocation information could come from
the user's device ip address, or the like. Alternatively, the user
can be asked to provide their location (although preferably the
information would be come from an automated source which is
presumably more reliable).
[0040] FIG. 5 discloses an additional embodiment of the invention
that generally takes place after the rules phase described above.
This phase of the invention involves procedures for setting fees
charged by the financial institutions for processing the users
transaction.
[0041] The process essentially begins with a check to determine if
the check has passed the prior rules. If not, the check is declined
and no fees are assessed. If yes, then a determination is made as
to whether the fee determination feature is enabled. If not, then
processing returns to the normal flow.
[0042] If the fee step is enabled, the first step performed is to
determine the fee according to the financial institutions
algorithm. This will vary from institution to institution, but
generally is based on a flat fee per transaction, or the fee can be
based on some percentage of the transaction amount, or some
combination of the foregoing. For example, if the check is under a
certain amount then a fixed fee applies, over a certain amount a
percentage applies, or vice versa. Next, the fee calculated
according to the algorithm is compared against maximum amount as
determined by the applicable legal standard in the jurisdiction
where the user is located. Location information can be obtained in
the manner described above in reference to the procedure describe
in FIG. 4.
[0043] The calculated fee is compared to the maximum fee (if
applicable), and the fee is set at either the lesser of the
calculated fee or the maximum fee. The user is then prompted to
accept the fee. If the fee is accepted then a transaction accepted
message is transmitted. If the fees are not accepted, the
transaction is cancelled.
[0044] In this manner the system of the present invention
substantially overcomes the limitations of the prior art. One of
the principle advantages of RDC systems is that they allow users to
remotely process financial transactions. This can be extremely
beneficial to merchants that can complete transactions at the point
of service, regardless of the location. It is also helpful to the
financial institution in that they can operate without limitation
as to physical location and reduce associated overhead. One
drawback of such an approach is that an entirely computer processed
transaction is subject to fraud, mistake, and manipulation as
computer systems are inherently limited with regard to the ability
to avoid such problems.
[0045] Additionally, the invention applies rules based methodology
that provides for security, processing efficiency, and
consistency.
[0046] Still further, the present invention can utilize
multi-factor authentication at the device and rule/review level to
ensure user authenticity. This is a system that requires the user
to provider more than one form of verification. For example, when
the user logs in they can provide a user name and password, and the
system could then require additional verification by sending an
email or text message to an account of device that would need
further action such as entering a password from the email or text
message, or requiring the user to select an enabling link. The
secondary authentication would ideally require the user to pass
through a level of security that is independent from the account
that is processing the financial transaction. Other devices that
can be used are a smart cards, security tokens, biometrics, and the
like. This would ensure that even if an unauthorized person gained
access to the device or account used to complete the financial
transaction they would need to have access to another user secured
account or device.
[0047] Further yet, all communications to the user described
herein, especially those to a user mobile device, can utilize push
notification technology and systems. The deposit of the financial
instrument can be made directly to the financial institutions CORE
(centralized online real-time environment), including if made from
a user mobile device.
[0048] The present invention solves this problem by providing a
human operator the ability to evaluate a transaction prior to
approval and therefore apply qualified and skilled expertise to the
transaction that is normally reserved for in-person transactions.
This advantage is provided without limiting any of the advantages
of RDC transactions or processing.
[0049] Unless otherwise defined, all technical and scientific terms
used herein have the same meaning as commonly understood by one of
ordinary skill in the art to which this invention belongs. Although
methods and materials similar to or equivalent to those described
herein can be used in the practice or testing of the present
invention, suitable methods and materials are described below. All
publications, patent applications, patents, and other references
mentioned herein are incorporated by reference in their entirety to
the extent allowed by applicable law and regulations. In case of
conflict, the present specification, including definitions, will
control.
[0050] The present invention may be embodied in other specific
forms without departing from the spirit or essential attributes
thereof, and it is therefore desired that the present embodiment be
considered in all respects as illustrative and not restrictive,
reference being made to the appended claims rather than to the
foregoing description to indicate the scope of the invention. Those
of ordinary skill in the art that have the disclosure before them
will be able to make modifications and variations therein without
departing from the scope of the invention.
* * * * *