U.S. patent application number 11/873845 was filed with the patent office on 2008-02-14 for method for transaction processing in a capture and deposit.
This patent application is currently assigned to JPMorgan Chase Bank, N.A.. Invention is credited to Jim P. Kerwood, Warren G. Lewis, S. Richard Re, Howard Shaw, Jason J. Strle, Sean Thornton.
Application Number | 20080040249 11/873845 |
Document ID | / |
Family ID | 39052015 |
Filed Date | 2008-02-14 |
United States Patent
Application |
20080040249 |
Kind Code |
A1 |
Re; S. Richard ; et
al. |
February 14, 2008 |
METHOD FOR TRANSACTION PROCESSING IN A CAPTURE AND DEPOSIT
Abstract
A system and method for processing transactions is disclosed.
The different processes are integrated by use of a controlling
processing engine which contains instructions on how the processes
should be treated. The system and method provides an end to end
integrated system for processing payments and reporting the
transaction results in real time. The system and method allows
customers to have access to the transaction data in real time and
return any excepted payments in real time.
Inventors: |
Re; S. Richard; (Westfield,
NJ) ; Shaw; Howard; (Old Bethpage, NY) ;
Strle; Jason J.; (Lewis Center, OH) ; Kerwood; Jim
P.; (Columbus, OH) ; Thornton; Sean;
(Columbus, OH) ; Lewis; Warren G.; (Chandler,
AZ) |
Correspondence
Address: |
HUNTON & WILLIAMS LLP;INTELLECTUAL PROPERTY DEPARTMENT
1900 K STREET, N.W.
SUITE 1200
WASHINGTON
DC
20006-1109
US
|
Assignee: |
JPMorgan Chase Bank, N.A.
270 Park Avenue
New York
NY
10036
|
Family ID: |
39052015 |
Appl. No.: |
11/873845 |
Filed: |
October 17, 2007 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11400171 |
Apr 10, 2006 |
|
|
|
11873845 |
Oct 17, 2007 |
|
|
|
60743157 |
Jan 20, 2006 |
|
|
|
Current U.S.
Class: |
705/35 |
Current CPC
Class: |
G06Q 40/00 20130101;
G06Q 40/02 20130101 |
Class at
Publication: |
705/035 ;
705/001 |
International
Class: |
G06Q 40/00 20060101
G06Q040/00; G06Q 10/00 20060101 G06Q010/00 |
Claims
1. A method of processing transactions, comprising: capturing data
based on one or more transactions; identifying each of the one or
more transactions as unique item; associating the one or more
transactions with one or more customers; and applying personalized
processing of the one or more transactions for each of the one or
more customers.
2. The method of claim 1, wherein the data is captured in at least
one of the following front end locations: ATM, branch, lockbox,
vault, and external customer-created location.
3. The method of claim 1, wherein capturing data comprises at least
one of image capture, scanning paper checks, and entering data in
computer-based form.
4. The method of claim 1, wherein each of the one or more
transactions is identified as at least one of the following
transaction types: credits, deposits, debits, checking,
withdrawals, payments, electronic payments, cards, and
miscellaneous real-time banking.
5. The method of claim 1, wherein associating the one or more
transactions with one or more customers is based on at least one of
the following transaction attributes: customer type, customer
activity, customer request, transaction value, transaction
frequency, transactions volume, and administrator override.
6. The method of claim 1, wherein associating the one or more
transactions with one or more customers is based on at least one of
the following environmental attributes: date, time, day of week,
time of day, market conditions, image quality, currency, and
geography.
7. The method of claim 1, wherein a central processing engine
applies personalized processing in real-time.
8. The method of claim 1, wherein the method of processing
transactions further comprises assigning attributes to the one or
more transactions.
9. The method of claim 1, wherein the method further comprises
processing transactions by at least one of file processing and
batch processing.
10. The method of claim 9, wherein the method further comprises
streaming real-time processing.
11. The method of claim 1, wherein the method of processing
transactions further comprises centralized settlement processing
for a variety of time frames based on the one or more
transactions.
12. The method of claim 1, wherein the method further comprises
processing transactions by at least one of serial and parallel
processing.
13. A computer readable media comprising code to perform the acts
of the method of claim 1.
14. A system of processing transactions, comprising: one or more
front end locations for capturing data based on one or more
transactions; one or more centralized processing engines for
identifying each of the one or more transactions as unique item,
associating the one or more transactions with one or more
customers, and applying personalized processing of the one or more
transactions for each of the one or more customers.
15. The system of claim 14, wherein the one or more front end
locations comprises at least one of an ATM, branch, lockbox, vault,
and external customer-created location.
16. The system of claim 14, wherein the data comprises at least one
of image capture, scanning paper checks, and entering data in
computer-based form.
17. The system of claim 14, wherein each of the one or more
transactions is identified as at least one of the following
transaction types: credits, deposits, debits, checking,
withdrawals, payments, electronic payments, cards, and
miscellaneous real-time banking.
18. The system of claim 14, wherein the one or more transactions
associated with one or more customers is based on at least one of
the following transaction attributes: customer type, customer
activity, customer request, transaction value, transaction
frequency, transactions volume, and administrator override.
19. The system of claim 1, wherein the one or more transactions
associated with one or more customers is based on at least one of
the following environmental attributes: date, time, day of week,
time of day, market conditions, image quality, currency, and
geography.
20. The system of claim 14, wherein the central processing engine
applies personalized processing in real-time.
21. The system of claim 14, wherein the one or more centralized
processing engines further assigns attributes to the one or more
transactions.
22. The system of claim 14, wherein the one or more centralized
processing engines further processes transactions by at least one
of file processing and batch processing.
23. The system of claim 14, wherein the system further comprises
streaming real-time processing in at least the one or more front
end locations and the one or more centralized processing
engines.
24. The system of claim 14, wherein the one or more centralized
processing engines further provides centralized settlement
processing for a variety of time frames based on the one or more
transactions.
25. The system of claim 14, wherein the one or more centralized
processing engines further comprises processing transactions by at
least one of serial and parallel processing.
26. A method of processing transactions, comprising: receiving one
or more transactions; associating the one or more transactions with
one or more customers, wherein associating the one or more
transactions is based on one or more attributes; persisting the one
or more attributes in one or more data storage systems; and
processing the one or more transactions for each of the one or more
customers based on the persisted attributes.
27. A method of processing transactions, comprising: capturing data
based on one or more transactions; identifying each of the one or
more transactions as unique item, wherein each of the one or more
transactions is identified as at least one of the following
transaction types: credits, deposits, debits, checking,
withdrawals, payments, electronic payments, cards, and
miscellaneous real-time banking; associating the one or more
transactions with one or more customers, wherein associating the
one or more transactions with one or more customers is based on at
least one of the following attributes: customer type, customer
activity, customer request, transaction value, transaction
frequency, transactions volume, date, time, day of week, time of
day, market conditions, image quality, currency, geography, and
administrator override; assigning attributes to the one or more
transactions; and applying personalized processing of the one or
more transactions for each of the one or more customers, wherein
personalized processing is provided in real-time.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] The present invention is a continuation-in-part (CIP) of
U.S. application Ser. No. 11/400,171, filed Apr. 10, 2006, entitled
"Method for Transaction Processing in a Capture and Deposit," which
claims priority to U.S. Provisional Application No. 60/743,157,
filed Jan. 20, 2006, both of which are incorporated herein by
reference in their entirety.
FIELD OF THE DISCLOSURE
[0002] The present disclosure relates generally to integrating
processes related to electronic payment, and is particularly
directed to data processing related to data capture and deposit
management systems.
BACKGROUND OF THE DISCLOSURE
[0003] The need to make and efficiently track payments is a major
concern for business and individuals alike. Generally, there are
separate lines of processing for each payment type and particular
payment locations may only accept or prefer certain payment types
but not others. For instance, a small merchant may not accept a
credit card because he does not want to pay the high cost of the
credit card payment transaction, just as a large entity may prefer
not to accept checks as payment due to the amount of manual labor
required to process the payment and the systemic risks. As
technology advances, both payees and payors will want faster, more
efficient, more secure, and more transparent payment processes
across all payment types. Convergence of payment types and changes
in security settlement regulations will result in a corresponding
convergence in delivery and payment channels. This evolution will
require financial institutions to: meet changing regulations; use
the most convenient payment instruments; improve productivity;
reduce operational, credit, and systemic risks; reduce costs and
capital investments; and improve funds availability.
[0004] Present payment solutions include Electronic Check Present
(ECP), Image Cash Letter Exchange Image Replacement Document (IRD),
Automated Clearing House (ACH), and ATM Enhanced Message Structure
(EMS), and credit cards. Based on processing cost, funds
availability, and credit and systemic risks, each has its
respective strengths and weaknesses. Each of the above solutions is
generally fixed to a single type of payment and does not integrate
processing across different payment types. Also, many of the above
solutions are cost prohibitive to all but the largest institutions.
In all solutions but ACH, the cost of presenting an electronic
check is projected to be more expensive than presenting a
traditional paper check. However, some merchants do not like to use
ACH as payment mechanism due to the potential payment risks. For
example, under ACH a return can occur 45 days after the good has
been provided to the consumer
[0005] In view of the disadvantages of the present state of the
art, it would be desirable to develop an integrated method for
end-to-end realtime capture, processing, management and clearing,
which increases availability, lower costs, reduce risks, and thus
overcomes the above-described inadequacies and shortcomings.
SUMMARY OF THE DISCLOSURE
[0006] The present subject matter relates to integrating
transaction processing. The different payment processes are
integrated by use of a controlling processing engine and processing
data related to transactions. In one embodiment, the system may
comprise:
[0007] an integrated distributed capture module for capturing data
at payment acceptance locations;
[0008] a central processing module, wherein the central processing
module accepts multiple payment types;
[0009] an electronic quality control module;
[0010] an electronic payment type determination module;
[0011] a payment processing instruction at the central processing
module, wherein the processing instruction includes customer
defined rules, processor defined rules, and regulatory defined
rules, [0012] wherein the payments are processed based on the
payment processing instruction;
[0013] a clearing module, [0014] wherein the clearing module
manages a transaction based on the payment;
[0015] a transaction management module for managing transmissions
and reports regarding the transaction in real time;
[0016] an inquiry management module for managing inquiries
regarding the transaction in real time.
In another embodiment, the method may comprise:
[0017] processing payments on a central processing engine that
accepts a plurality of payment types, wherein the central
processing engine processes the payments based on processing
instructions, wherein the processing instructions include at least
a customer defined instruction, a processor defined instruction,
and a regulatory defined instruction;
[0018] capturing data related to a payment at a payment accepting
location;
[0019] transmitting captured data to the central processing
engine;
[0020] reviewing the captured data for quality of capture;
[0021] recognizing the type of payment from the captured data;
[0022] reporting transaction data in real time; and
[0023] providing access to the real time transaction data.
[0024] In another embodiment the integrated system may comprise
capturing data at payment acceptance locations, such as branches,
payment centers, cash register, cashiers, payment/receivable
processing centers, etc.; a processor to review the quality of the
captured data; a payment neutral processing engine that processes
exceptions, manages transactions, including reporting to and
answering inquiries from customers, creating files; routing images,
data and electronic transactions through appropriate payment
channels based on customers' and financial institutions' clearing
profiles.
[0025] Some of the features in the present disclosure include: (1)
the ability to convert one type of payment, such as a physical
check, into another type of payment, such as a purely electronic
transaction; (2) the ability to report or access real-time
transaction data; (3) the web-enabled access; (4) the ability to
enable payors, payees, processors, their agents or other interested
parties to choose appropriate payment channels to clear payments;
(5) the ability to detect high risk transactions, which reduces
fraud and prevents double posting; and (6) the ability to tailor
the system design for changing needs.
BRIEF DESCRIPTION OF THE DRAWINGS
[0026] In order to facilitate a fuller understanding of the present
disclosure, reference is now made to the accompanying drawings.
These drawings should not be construed as limiting the present
disclosure, but are intended to be exemplary only.
[0027] FIG. 1A is a schematic block diagram of an integrated system
in accordance with one embodiment of the present disclosure.
[0028] FIG. 1B is a schematic block diagram of the capture and
deposit management system in accordance with an embodiment of the
present disclosure.
[0029] FIGS. 2A-2B are flowcharts depicting the steps carried out
by the branch capture module in accordance with an embodiment of
the present disclosure.
[0030] FIGS. 3A-3D are flowcharts depicting the steps carried out
by the central image and data capturing and processing module in
accordance with an embodiment of the present disclosure.
[0031] FIGS. 4A-4F are schematic block diagrams of the transaction
management module in accordance with an embodiment of the present
disclosure.
[0032] FIGS. 5A-5D are schematic block diagrams of the images and
electronic transaction clearing module in accordance with an
embodiment of the present disclosure.
[0033] FIG. 6 is a flowchart depicting the steps carried out by the
return items module in accordance with an embodiment of the present
disclosure.
[0034] FIG. 7 depicts a schematic block diagram of a system for
processing messages in accordance with an embodiment of the present
disclosure.
[0035] FIG. 8 depicts an exemplary flowchart of a method for
processing messages in accordance with an embodiment of the present
disclosure.
DETAILED DESCRIPTION
[0036] With reference to FIG. 1A, a payor 100 would make a payment
at a payment acceptance location 3 to the payee 6. The payment
acceptance location 3 may be, for example, a branch of a financial
institution, a payment center, a back office, a payment processing
center, an ATM machine, a cash register, a cashier, point-of sale
(POS) locations, central processing sites etc. The payor 1 will
present a payment to the payment acceptance location 3. The payment
will have a payment type and a payor drawon 2, which is an account
and/or institution where the funds will come from. For example, if
the payment type is a check, the payor drawon will be the bank and
account the check is issued from. If the payment type is a credit
card, the payor drawon can be the credit card company and account
the card is issued from. The payor drawon can be, for example, a
bank, a mutual fund, a credit card company, or any other account
where funds can be drawn from. These parties need not be distinct
entities. For example, it is possible that the payee 6 and payor
drawon 2 are the same entity. Payment types can include, but are
not limited to, paper checks, electronic checks, ACH, debit cards,
credit cards, and stored value cards. The payor does not need to
bring the payment in person, but those of ordinary skill in the art
will understand that the invention also applies to electronic
payments, payments mailed in or sent in to a location, or any other
conventional payment arrangements.
[0037] The payment acceptance location 3 will capture data related
to the payment. For instance, if the payment type is a check, the
image of the check can be digitally captured. In another
embodiment, the payment type can be a debit or credit card and the
data capture can include data obtained from the magnetic stripe or,
in the event the debit or credit card is not present, can digitally
image a coupon containing the card account information. In other
embodiments, other details can be captured on the coupon, such as
billing information.
[0038] Once the data is captured, the data is transferred at 4 to a
processor or group of processors 6 that will review the image for
quality and completeness and determine the payment type from the
captured data. Payments may be rejected for several reasons,
including, but not limited to fraud (e.g., (invalid signature,
invalid account), payment risks (e.g., non-sufficient funds, stop
checks), unacceptable payment based on client instructions,
unacceptably poor image quality, checks do not meet regulatory
requirements (post date, stale date, not endorsed, etc.). In the
event the data capture does not meet the quality standards, the
data can be rejected at 7 and the processor may notify the payment
acceptance location 3 in real time that the data is unacceptable
and may request for the data to be recaptured. The recognition and
quality control processor can be located at the payment acceptance
location 3, at a third party transmission site, or within the
payment processor's system 5.
[0039] After recognition and quality control 6, the captured data
can then be sent to the processing engine 9. The engine processes
the payments, regardless of type, according to a set of processing
instructions. The engine can consist of one processor or a multiple
processors and systems. The processing instructions may include
rules such as what order the payment types should be processed,
whether processing should take place in real time or in batch, the
type of reporting to be sent out, and whether incoming payment
types should be converted to another payment type for processing.
Generally, there are three contributors to the processing
instruction. The customer, who may be the payee, the payee's agent
or any one who will benefit from the transaction, the payment
processor 5, and a regulatory agency, such as the Federal Reserve
or NACHA. These parties need not be distinct entities. For example,
it is possible that the customer instruction and payment processor
instruction are the same. These rules can provide the customer
setup and profile management and contain instruction on area such
as product usage, deposit positing criteria, availability
schedules, deposit/ledger cut-off times, notification criteria,
transmission timing, and formats and pricing records, providing
clearing recipient set-up and profile management. These rules can
help to speed the clearing process, reduce expense, be more
efficient, or reflect what ever goal the requesting party needs to
be achieved. For example, payee may have a rule that requests all
payments be converted into ACH payments because the payor will be
credited faster. This would allow any payments to the payee to be
processed as ACH, regardless of whether the payment type was a
check, debit card or another payment type. However, all the
processing instructions must be followed. For example, the
regulatory agency may have a rule that prohibits credit card
payments from being converted to ACH. That payment will proceed as
a credit card transaction unless there is another non-conflicting
rule that deals with its processing.
[0040] In another embodiment, other parties may contribute to the
processing instructions. For, example, the payor drawon 2 may
request that all funds drawn from their account happen in real time
instead of in batch. A clearinghouse associated with processing the
payment may add its own rules.
[0041] Moreover, the processing instructions may also include a
means for determining a high risk payment. A database or collection
of databases with high risk factors can be used to determine if a
transaction is high risk. The databases can be internal, external,
proprietary or public and risk factors can include low credit
scores, previous payee fraud, low account balances, or if the payee
has a high return rate. The risk factors can also focus on the data
capture such recognizing differences in signatures, improper
payment type forms. The amount of risk a payment can have may be
set by the rules provided by the relevant parties. If the risk
tolerance is exceeded, the processing instructions may require that
the payment be denied or noted as an exception. If the payment is
too risky, notification may be sent to the payee 6, payor drawon 2
and/or payment accepting location 3 in real time.
[0042] After the payment has been processed according to the
processing instructions the processing engine 9 may also have a
clearing function that processes the transactions 10 related to the
payments. For instance, the transaction 10 could consist of
debiting and/or crediting the respective accounts. The processing
engine 5 can then report information about the transaction to the
payee 6, the payor drawon 2, or any other designated party in batch
or real-time. The processing instructions may include instructions
on what format the reports should take, the content of the reports
and who the reports should go to. The reports may include
information about the status of the transactions, when credit will
be available, when a debit will be taken, provide an alert for an
exception, or anything else about the transaction a party wishes to
know.
[0043] In an embodiment, an interested party, such as the payor 1,
the payment acceptance location 3, the payor drawon 2 or the payee
6, or an outside party acting as an agent for an interested party
may access the in real time 12, giving the party the ability to
inquire about a specific transaction in real-time. For example,
this would provide the payee 6 with an increased degree of
flexibility. It allows the payee to look proactively for specific
information as opposed to just waiting for the report and looking
line by line for the desired transaction. This allow the payee to
proactively manage its accounts. Real time reporting and party
inquiries can be transmitted in a manner known in the art, such as
through the Internet, an intranet, email, instant messages, or
other transmission means conducive to real time notification or be
updated to the client's accounting systems of payment and
information, such as receivables, invoice, inventory, banking
accounts, brokerage accounts, etc.
[0044] The present invention may be used alone or in conjunction
with other payment processing solutions such as lockboxes,
distributed check capture devices, credit card capture devices,
Accounts Receivable and other accounting systems.
[0045] With reference to FIG. 1B, an embodiment is shown for
transaction processing in a capture and deposit management system
100. The method may comprise the following functions: capturing
data at payment acceptance locations; capturing and processing data
at central processing sites including processing exceptions, and
proof and control; managing transaction including reporting to and
answering inquiries from customers; creating files; routing data
and the transactions through appropriate payment channels based on
customers' and financial institutions' clearing profiles; and
processing return payment data. The capture and deposit management
system may comprise five interactive functional modules: (1) a data
capture module 101 that captures data such as check images at
payment acceptance location 3; (2) a central data capturing and
processing module 102 for data entry, image capturing and/or
processing, exception processing, and proof and control; (3) a
transaction management module 103 for reporting and inquiry, file
creation, and transmission management; (4) an data and transaction
clearing module 104 that routes both data and transactions through
appropriate payment channels based on customers' and financial
institutions' clearing profiles; and (5) a return payment module
105 that processes the return payment data, and interfaces with
both the data and transaction clearing module and the transaction
management module.
[0046] FIG. 2A depicts an embodiment where a customer submits a
check for payment at a bank branch 201, Branch personnel review the
item(s) for both generally accepted standards of negotiability as
well as acceptability 202. If the checks do not meet these
criteria, they can be immediately returned to the customer(s) with
an explanation, and an alternate payment form may be arranged 203.
If the item(s) meets negotiability and acceptability, branch
personnel identify the transaction type (single check with coupon,
multiple checks with coupons, or check only) 204. The branch
personnel must designate the transaction type. For "multiple checks
with coupons" transaction type, the transaction order is <Start
of Transaction> Coupon 1, Check 1, . . . , Check N <End of
Transaction> 205. For "single check with coupon" transaction
type, the transaction order is <Start of Transaction> Coupon,
Check <End of Transaction> 206. For "check only" transaction
type, if there is only one check 207, the transaction order is
<Start of Transaction> Check <End of Transaction> 208;
if there is more than one check, checks are processed as one
transaction, a deposit coupon is added 209, and the transaction is
considered a "multiple checks with coupon" transaction type 205. In
correct transaction order, images of check(s) and coupon are
captured; check's data are read by magnetic ink character
recognition technology (MICR); coupon's data are read by optical
character recognition technology (OCR); and a unique identification
number is sprayed on each item 210. Branch personnel then review
the captured images to ensure good quality 211. If the captured
images are unreadable, the corresponding checks and coupons need to
be rescanned.
[0047] With reference to FIG. 2B, the deposit data are then matched
against a stop file 212. If a customer account has been designated
not to accept deposits, the matched items will be flagged and a
message will be displayed to branch personnel 213. If certain
payment types require additional review 214, those items will be
flagged and a message will be displayed to the branch personnel.
The branch personnel will send these items to an exception process
for further disposition 215. The captured images and data are
stored locally in a processing category and transmitted to a
central processing site along with branch and workstation
information 216. The transmitted images and data are secured,
authenticated and non-repudiated. The transmission may use XML
message format along with web services that can either be
transmitted via private network or internet. The central processing
site then transmits an acknowledgement (ACK) file for each item
received 217. At the end of day the central processing site
provides a detailed report on all deposits and checks transmitted.
The physical deposit ticket and checks are boxed, sealed for
storage, and truncated either locally or in a central processing
location per destruction procedures 218. Once the images and data
are transmitted to the central processing site, transaction
proceeds to the processes of data and image capturing and
processing module at a central processing site 300.
[0048] The data capture module 101 may comprise: means for
reviewing payments for negotiability and acceptability; means for
determining transaction type; an image capture device for capturing
images and data of the payments, and spraying an identification
number on each item of the captured payments; means for matching
the captured data against a stop file; and means for transmitting
the captured images and data to a central processing site. The
image capture device may comprise a scanner which can capture
images and read data, a computer, a storage device, and a device
for spraying an identification number. The means for matching the
captured data against a stop file may be a computer, a special
software, and database, which can determine whether a customer
account has been designated not to accept payments, and certain
payment types require additional review. The means for transmitting
the captured images and data to a central processing site may be a
web service such as private network or internet.
[0049] With reference to FIG. 3A in another embodiment, as a
central processing site receives captured images and data from
payment acceptance locations 301; it will thereafter transmit an
acknowledgement file for each received item 302. In the meantime,
the central processing site also receives lockbox payments 303. All
lockbox items are received multiple times per day. The schedule is
monitored and modified as necessary to optimize the mail
availability. The following procedures are similar to the ones
occurring in branches, which are illustrated in 2.1-2.2 of FIG. 2A
304. The lockbox items are sorted into one of the three categories:
(1) single payment with deposit coupon, (2) multiple payments with
deposit coupon, and (3) payment(s) only. For each of these batch
types, site personnel examine payments for general negotiability
and acceptability. All lockbox payments are then captured via
high-speed scanner. Payments and coupons remain associated
throughout the scanning process similar to the procedures occurring
in payment centers. From point of capture forward, payment
acceptance location and lockbox payments will be processed
according to the same basic workflow, as described below. Templates
for each payment type that will map to specific fields and business
rules are set up ahead of time. Using a high-resolution image of
each payment form, the system will be instructed to map particular
form elements to one of the identified fields. Landmarks are
identified to perform automatic form identification and orient
captured images for locating field elements 305. The next step is
form identification 306. If the form cannot be identified, it will
be manually reviewed and processed 307. Forms are identified based
on a combination of visual characteristics and a form ID number.
Each form has a "visual fingerprint" for the system to make
high-speed determinations. Once the system has narrowed the field,
it can look further for a form ID.
[0050] With reference to FIG. 3B, as the form type is identified,
intelligent character recognition technology is applied to the
designated fields 308. Software will automatically attempt to read
the fields 309. Any fields that cannot be read automatically will
be displayed for keying. If the form is missing mandatory
information 310, site personnel will decide resubmit or reject the
transaction 311. If the site personnel decide to resubmit the form,
they will fill in missing information 312. The rejected
transactions will be placed in an exception queue and sent back to
the branch with its status updated 313.
[0051] With reference to FIG. 3C, customer account number is then
identified and read via the intelligent character recognition
technology 314. If the account number is on a document with an
optical character recognition (OCR) scan line 315, check digit
validation is required 316. If the account number is on a document
without an OCR scan line, verification of the handwritten account
number is required 317. The following procedures 318 are similar to
the ones occurring in branches, which are illustrated in
2.2.about.2.3 of FIG. 2B. Customer accounts are compared against a
stop file to identify accounts which are designated not to accept
deposits and possible fraudulent payments. Any identified items
will cause the entire deposit to be rejected. A reason code will be
added to these rejected items. If the items came from a payment
acceptance location, that payment acceptance location will receive
notification and the status of the transaction will be updated.
[0052] With reference to FIG. 3D, coupon and payment amounts are
then compared 319 to determine whether the amounts match 320. If
the amounts do not match, they are sent to site personnel for
review 321. If the site personnel can resolve the discrepancy, he
will re-key 322. If the site personnel cannot resolve the
discrepancy, there are several options: reject the transaction and
send to exception queue; force balance by keying leftover amounts
into separate field and set out of balance flag; key a designated
number into coupon amount field to flag item as out of balance
323.
[0053] As the amounts get matched, the payments are reviewed to
determine whether the payment is cash-like instrument 324. If the
payment is a cash-like instrument, a designated code is assigned to
each payment 325. Then an availability code will be assigned to
each payment based on account number and branch location 326. If
the system requires more detailed availability coding 327, the
central processing site will submit the items to the images and
electronic transactions clearing module 328. Once a clearing method
was determined, the image and electronic transactions clearing
module will send that information to the central processing site
329.
[0054] A posting file is created hourly for the items processed.
This file will not be cumulative. Each hour this file is
transmitted from the central processing site to the transaction
management module. The images and data associated with each
transaction will be included in this transmission 330.
[0055] The central data capturing and processing module 102 may
comprise: means for receiving transmitted captured images and data
from payment acceptance locations; means for receiving lockbox
payments and determining transaction type; an image capture device
for capturing images and data of lockbox payments; means for
identifying payment form types; means for processing payment forms;
and means for transmitting posting files of processed items
together with images and data to the transaction management module.
The means for receiving transmitted captured images and data from
branches may comprise computer connected, web service, data storage
device, and software. An image capture device for capturing images
and data of lockbox payments may comprise scanner, computer, data
storage device, device for spraying identification number on each
item, and software. The means for identifying payment form types
may be form identification software. The means for processing
payment forms may be software performing the designated functions.
The means for transmitting posting files of processed items
together with images and data to the transaction management module
may comprise computer, software, and web service.
[0056] With reference to FIG. 4A, transaction management 400
comprises: customer self-service 401; central control 402;
monitoring and control 403; transmission 404; financial reporting
405; archive 406; transaction routing 407; and customer profile
setup 408.
[0057] With reference to FIG. 4B, The customer self-service 401 is
a real time internet-based web browser application (however, any
communication means conducive to real time transmission is
acceptable) which can perform self service 410, provide transaction
processing status 411, view exceptions 412, and perform user
Administration 413. The exception processing 412 comprises same day
exceptions 418 and returned payments 419. The self service 410
comprises transaction search and inquiry 414, transaction image
retrieval and views 415, reporting and downloads 416, and
information uploads 417. The self service 410 allows a customer to
inquire about captured, processed or exception transactions. It
provides the ability to inquire about batch processing status. It
can also deliver alerts on requirements. Personnel can search and
view processed transactions, and retrieve the transaction images to
service customers. The viewed image could be a remittance coupon, a
full page document or a check. The transaction detail and their
respective images can be displayed on the same viewing page or just
the images themselves. The search function provides any number of
ways to find a transaction. Deposit information can be viewed from
same day real time up to a designated period of time (say 1 month,
3 months, 1 year). The system can view and download reports and
other summary information related to their Lockbox activity.
Reports can even combine lockbox activity with associated
electronic payment activity. At the end of day, daily transaction
reports can be either viewed online, or printed, or downloaded as
XML, CVS or HTML file. Files can also be uploaded and sent to
designated operations.
[0058] Providing transaction processing status function 411 will
provide personnel with the status of a transaction in real time.
This allows personnel to view all the transactions and their
respective processing status. Personnel can see whether a
transaction was transmitted successfully to the central processing
site. This function will also display the status of processing
steps within the transaction management module. Viewing exceptions
function 412 will allow personnel to view any exceptions. This
facility has two functions. The first is to view the real time same
day exceptions. These exceptions could be a check that has a "stop
pay" placed on it, or a closed or dormant account, or a bad account
number, or had already been posted. They could also be foreign
checks, or payments that match stop pay criteria, or payments that
do not pass image usability standards and require rescanning, or
checks that fail internal processing rules. These exceptions may
need to be pulled manually from the work to be reviewed and they
would require further disposition. The viewing exceptions function
will also allow personnel to view returned checks. Personnel can
then contact their customers to inquire whether the returned
payments should be re-deposited. A designated security officer can
be made as a user administrator 413. This administrator can assign
id and roles to both branch and central operation personnel. This
application allows only designated personnel to access designated
functions.
[0059] With reference to FIG. 4C, the central control 402 is an
intranet web browser application for viewing processed transactions
and their status. In addition to performing the same functions
420-429 of the customer self service, it has additional return
items disposition function 430 and a more robust system
administration and management reporting function 431. The central
control can select eligible return items to be re-deposited online
either centrally or from a payment acceptance location. The
management reporting has a list of operations and financial reports
that can be selected for use or customized as required.
[0060] With reference to FIG. 4D, the monitoring and control 403
can monitor transaction processing status with an enhanced viewer
432. It can use this monitoring facility to alert management to
ensure that transactions are processed with priority and meet
customer's processing deadlines 433. This facility can perform
administrative functions such as setting up customer's processing
profile, image profile, alert profile, reports, transaction
decision and routing, return items, transmission requirements, and
other processing requirements that customers may have for their
payments 434. This facility also provides numerous management and
financial reports to the central processing site 435. These reports
will allow the central processing site to monitor the quality of
processing, work load balancing, and ensure work processed with
priority. These reports will provide financial reporting,
availability reporting, and balancing reporting.
[0061] The transmission function 404 can be configured to use a
number of standard file formats to transmit files on an hourly
basis or at any interval. It can also be customized to receive the
stop pay file and other special instructions.
[0062] The transaction management module provides a number of
management reports to perform financial balancing and reconcile
details 405. It also provides daily deposits and transaction
availability. The function provides a number of management reports
on daily processing, exception, return, and other critical
processing information by payment acceptance location.
[0063] The transaction management module stores both transactions
and images in its archive 406. This information is stored for
customer service to search and research transactions and retrieve
associated images. The archive will track payments clearing methods
along with the availability assignment.
[0064] With reference to FIG. 4E, the transaction routing function
407 ensures a transaction to move from one step to another step
436. This includes: remote capture, data and image processing,
transmission, customer service, and to and from the archive. This
function will send transactions and images to the images and
electronic transaction clearing module and the return items module
437. These two modules will receive transaction information such as
return items, exception/reject/duplicate transactions, deposit
transaction availability, and transaction clearing method along
with their processing status. This function will also trigger
alerts to notify exceptions or any transaction information required
438. In addition, the transaction routing provides status
information to the monitoring and control function 439.
[0065] With reference to FIG. 4F, the transaction management module
can customize process through its customer profile setup function
408, which includes setup of: transaction capture mode 440; image
form scanning for ICR 441; stop pay 442; special instruction
processing 443; transmission data format 444; transmission protocol
445; check availability assignment 446; daily deposit availability
based on check clearing methods 447; image and transaction archive,
CD creation and delivery 448; and return items instructions
449.
[0066] The transaction management module 103 for managing
transaction including reporting to and answering inquiries from
customers via internet or other communication means, and creating
files, comprises: means for customer self-service; means for
central control; means for monitoring and control; a transmission
facility; means for financial reporting; archive; means for
transaction routing; and means for customer profile setup. The
transaction management module may comprise web service, enhanced
viewer, computer, software, database, and storage device.
[0067] Routing both images and electronic transactions through
appropriate payment channels based on customers' and financial
institutions' clearing profiles 500 provides a single payment
management engine for all inbound and outbound electronic payments,
and establishes an architecture that can interface with all payment
and money movement applications. This method is built on an open
infrastructure that provides a web service interface using standard
XML messaging as well as the standard check data and image formats.
With reference to FIG. 5A, this method consists of the following
functions: communicating payment images and data with other systems
501, customer profile and processing assignment 502, float
assignment 503, transaction sorting and routing 504, providing
deposit posting and pending transaction controls 505, clearing by
payment channels 506, and settlement and reporting 507.
[0068] With reference to FIG. 5B, the customer profile and
processing assignment 502 provides the customer setup and profile
management including: product usage 508, deposit positing criteria
509, availability schedules 510, deposit/ledger cut-off times 511,
notification criteria 512, transmission timing 513, and formats and
pricing records 514. It also provides clearing recipient set-up and
profile management.
[0069] With reference to FIG. 5C, the float assignment 503 provides
unique availability tables to assign deposit availability to
customers 515. These tables can be accessed and updated via the
central control. This function provides multiple availability
assignment capabilities by capture site, device, time,
routing/transit numbers, and day of week 516. This function also
provides product item pricing to appropriate billing systems 517,
data for pricing and volume integrity proof and control 518, and
associated product and item cost data for product profitability
management 519.
[0070] The transaction sorting and routing 504 provides transaction
routing and posting control including transaction summary
information, adjustments, return items and availability assignment.
This function selects the optimum electronic payment channel for
each processed item based on risk, cost, clearing rules, and
schedules. This function will also perform exception processing on
the same day as the transaction is processed. This exception
processing includes handling account number editing, stop payment,
and closed/dormant accounts.
[0071] In addition, payments are matched against transaction
database to prevent double posting. The payment images and data
will be sent to the payment channels for clearing.
[0072] With reference to FIG. 5D, the clearing by payment channels
function 506 for image-based check processing include: electronic
check presentment (ECP) with image via SVPCO 520; electronic check
presentment (ECP) with image via direct correspondent transmission
521; accounts receivable conversion (ARC) channel for check
conversion to automated clearing house (ACH) 522;
[0073] and image replacement document (IRD) for imaged checks that
cannot be cleared via ECP or ARC 523.
[0074] The settlement and reporting function 507 provides deposit
and balance reporting data, and customer transaction details. This
function also provides reconcilement, proof and control, and
adjustment functionality for all system interfaces including
delivery channels, facing applications, specific business services
and payments channels as well as shared operation support channels
like customer service centers, and image and data archive.
[0075] The data and transaction clearing module 104 for routing
both data and transactions through appropriate payment channels
based on customers' and financial institutions' clearing profiles
comprises: data and transaction interface; means for customer
profile and processing assignment; means for float assignment;
means for transaction sorting and routing; warehousing and pending
database; payment channels; and means for settlement and reporting.
The data and transaction clearing module may comprise web service,
computer, software, database, and storage device.
[0076] FIG. 6 is a flowchart showing a process of handling returned
payments by a returned payment processing module in accordance with
one embodiment of the present invention. When a payment clearing
module receives a returned payment 600, it will send it to the
returned payment processing module 601. The returned payment
processing module then sends the returned payment with the original
client information to the payment management module 602. The
payment management module then tries to automatically match the
returned payment with its transaction history database 603. If it
can, it will retrieve the customer's original transaction
information 604. If it cannot, an office personnel will manually
research and key in any missing information 605. The returned
payment's data and images will be made available to the central
control sub-module and the customer's self service sub-module of
the payment management module 606. Then it is decided by the
customer and the financial institution whether the returned payment
may be re-deposited 607. If yes, the re-deposited payment is sent
to the returned payment processing module for further processing
608.
[0077] Since many current transactions are processed in batch mode,
whenever there is a problem with any one item, the entire group (or
batch) is delayed until the one item is corrected or verified
thereby resulting in processing inefficiencies. As a result, it
should be appreciated that in addition to handling transactions in
file/batch mode where groups of transactions are processed
together, embodiments of the present disclosure may also handle
each transaction as a unique item on an individual basis.
Embodiments of the present disclosure may further provide a new
architecture for real time processing of transactions as unique
discrete items.
[0078] During the lifespan of a transaction, for example, a system
and method may be provided for assigning specific attributes to
each transaction. In one embodiment, a credit may be identified and
associated with a customer, e.g., Customer A. The system may
recognize that Customer A is a preferred customer with excellent
credit history. The system may also recognize that Customer A makes
timely payments. The same credit may also be identified and
associated with another customer, e.g., Customer B. Although the
transactions appear identical, the system may distinguish the
transactions based on different customer types. In addition, the
system may consider a combination of transaction attributes (e.g.,
customer type, customer activity, etc.) and may process each
transaction in a different personalized manner. Therefore, if
Customer B is identified as a delinquent customer, the system may
apply various fraud processes against the transaction associated
with Customer B by checking for signatures, checking for balances,
checking for more recent check activity, and/or other similar
fraud-identification processes. In this example, customers may be
differentiated on an individual basis so that personalized services
may be more easily provided. Furthermore, an automatic trail of
transactions may be compiled, which may be useful for searching
and/or processing against it. For instance, if a
fraud-identification process was run against an account, not only
would the process be recognized, but information regarding the
process (e.g., results of the fraud check) may also be stored and
maintained. Accordingly, a customer service representative who is
interacting with a customer whose account was checked (e.g.,
Customer B) may have access to such information and may be able to
detail to Customer B exactly what processes and why they
occurred.
[0079] It should be appreciated that control software for
processing such transactions may be also be centralized. Instead of
having separate front-end applications that image the check (or
other instrument), embodiments of the present disclosure
re-architects the entire flow for the entire banking system so that
transaction information may be captured at various front-end
systems, such as ATM, branch, lockbox, etc., and processed in a
centralized manner.
[0080] FIG. 7 depicts a schematic block diagram of a system for
processing messages 700 in accordance with an embodiment of the
present disclosure. In this example, the system 700 may include one
or more front end systems/locations, a centralized processing
engine 710, and a settlement box 720. Other various processing
components may also be provided.
[0081] The one or more front end systems/locations may of the
system 700 may capture data based on one or more transactions. In
one embodiment, the one or more front end systems may include at
least one of an ATM 702, a branch 704, a lockbox 706, a vault
(e.g., check safe), or other front end system 708, such as an
external customer-created location (e.g., Internet, web browser,
etc.). The captured data may include at least one of captured
images, scanned paper checks, entered data in computer-based form,
or other similar data. Each of the one or more front end systems
may also be coupled to the centralized processing engine 710. Other
various embodiments may also be provided.
[0082] The centralized processing engine 710 may provide
centralized processing of the one or more transactions for each of
the one or more customers and may perform a variety of centralized
processes. The settlement box 720 may be coupled to the centralized
processing engine 710 to provide centralized settlement processing
for a variety of time frames based on the one or more transactions.
Other various embodiments may also be provided.
[0083] Although each of the front end systems, centralized
processing engine 720, and the settlement box of the system 700 is
depicted as a single component in FIG. 7, it should be appreciated
that each component may be combined into greater or fewer numbers.
These components may be local, remote, or a combination thereof to
each other. It should also be appreciated that the components of
the system 700 may also be coupled to one or more data storage
systems and/or servers (not shown). These one or more data storage
systems and/or servers may store and process relevant information
received from one or more service clients and/or other message
senders. Exemplary information may include a variety of offered
services, particularly financial or banking related services. It
should be appreciated that the one or more data storage systems
and/or servers may be combined into fewer or greater numbers of
data storage systems and/or servers to store and process the
received information. Furthermore, the data storage systems and/or
servers may be local, remote, or a combination thereof to each
other. Additionally, the databases and/or servers may also store
and process additional relevant information which may further
relate to processing transactions or other similar services, such
personalized customer information or information found in metadata.
Other variations may also be provided.
[0084] It should also be appreciated by one of ordinary skill that
each of the components in system 700 may include one or more
processors (not shown) for processing one or more messages. Data
may be processed for storage, indexing, categorizing, and/or
settlement by one or more processors of the components of system
700. By storage, indexing, categorizing, and/or settlement, the
data/information may be shared by multiple components and/or other
external systems. Such use may be sequential or simultaneous.
Furthermore, processing the data in this way may also allow the
processing logic to of any one of the components of system 700 to
cross-reference the various data/information for efficient use by
the system. Other various embodiments may also be provided.
[0085] FIG. 8 depicts an exemplary flowchart of a method for
processing messages 800 in accordance with an embodiment of the
present disclosure. The exemplary method 800 is provided by way of
example, as there are a variety of ways to carry out methods
disclosed herein. The method 800 shown in FIG. 8 may be executed or
otherwise performed by one or a combination of various systems. The
method 800 is described below as carried out by the system 700
shown in FIG. 7 by way of example, and various elements of the
system 700 are referenced in explaining the example method of FIG.
8. Each block shown in FIG. 8 represents one or more processes,
methods, or subroutines carried in the exemplary method 800. A
computer readable media comprising code to perform the acts of the
method 800 may also be provided.
[0086] Referring to FIG. 8, the one or more front end
systems/locations may capture data based on one or more
transactions 810, as described above. In addition, the centralized
processing engine 710 may identify each of the one or more
transactions as unique item 820, associate the one or more
transactions with one or more customers 830, and apply personalized
processing of the one or more transactions for each of the one or
more customers 840.
[0087] In one embodiment, each of the one or more transactions may
be identified as at least one of the following transaction types:
credits, deposits, debits, checking, withdrawals, or other
real-time banking transaction type. It should be appreciated that
these may further include, but not limited to, payments, electronic
payments, card payments, etc. In another embodiment, the one or
more transactions associated with one or more customers may be
based on at least one of the following transaction attributes:
customer type, customer activity, customer request, transaction
value, transaction frequency, transactions volume, and
administrator override. In yet another embodiment, the one or more
transactions associated with one or more customers may be based on
at least one of the following environmental attributes: date, time,
day of week, time of day, market conditions, image quality,
currency, and geography. It should be appreciated that a currency
attribute may include, but not limited to, multi-currency
processing, conversion, and exchange. Other various embodiments may
also be provided. The central processing engine 710 may also apply
personalized processing in real-time.
[0088] As discussed above, the centralized processing engine 710
may also include one or more processors and instructions to perform
additional features. For example, the centralized processing engine
710 may also assign attributes to the one or more transactions,
process transactions by at least one of file processing and batch
processing, and/or provide centralized settlement processing for a
variety of time frames based on the one or more transactions. For
example, in another embodiment, processing transactions by at least
one of serial and parallel processing may be provided. In another
embodiment, streaming real-time processing in at least the front
end systems/applications, the central processing engine 710, the
settlement box 720, or other various processing component (e.g.,
backend system/application) may be provided. Other various
embodiments may also be provided.
[0089] It should be appreciated that after the one or more front
end systems/locations capture data based on one or more
transactions 810, the data may be transmitted for at least one of
serial and parallel processing. Furthermore, it should be
appreciated that while exemplary method 800 depicts four distinct
blocks, the method 800 may selectively bypass one or more of the
blocks to processing one or more of the transactions. Such a
feature may provide a flexible and efficient approach to processing
transactions. Additionally, it should be appreciated that once the
one or more transactions are associated with one or more customers
830, intelligent routing may be provided from one or more
overburdened or offline centralized processing engines to other
alternate sites or instances so that network and/or resource
utility is maximized.
[0090] It should also be appreciated that a state of one or more
transactions may be tracked. For example, in one embodiment, one or
more transactions may be received for associating with one or more
customers. In this example, associating the one or more
transactions may be based on one or more attributes (e.g.,
transaction, environmental, etc.). In addition, the one or more
attributes may be persisted in one or more data storage systems to
provide a record of transactions and/or full searching capabilities
for retrieval, modification, and other processing actions. The one
or more transactions for each of the one or more customers may be
further processed based on the persisted attributes. As a result,
during the entire life cycle of a transaction, the transaction
never leaves. Rather, the transaction may change states (e.g., by
the various attributes) to ultimately provide a way of processing
transactions that is comprehensive and efficient.
[0091] Through a centralized system, embodiments of the present
disclosure may provide a consistent approach for settlement for the
entire system 700, e.g., banking system. Rather than invoking
different settlement routines, the centralized system and method
may process one or more settlements on a variety of time frames
based on the receiving applications. Thus, an intelligent platform
may be created where transactions can be recognized by the system
and the system identifies how to process the transaction on an
individualized manner. Other various benefits and advantages may
also be provided.
[0092] The present disclosure is not to be limited in scope by the
specific embodiments described herein. Indeed, other various
embodiments of and modifications to the present disclosure, in
addition to those described herein, will be apparent to those of
ordinary skill in the art from the foregoing description and
accompanying drawings. Thus, such other embodiments and
modifications are intended to fall within the scope of the present
disclosure. Further, although the present disclosure has been
described herein in the context of a particular implementation in a
particular environment for a particular purpose, those of ordinary
skill in the art will recognize that its usefulness is not limited
thereto and that the present disclosure may be beneficially
implemented in any number of environments for any number of
purposes. Accordingly, the claims set forth below should be
construed in view of the full breadth and spirit of the present
disclosure as described herein.
* * * * *