CA2858304A1 - System and method for digital document management - Google Patents

Abstract

A method and system for processing an application for a financing product for a user in an electronic financing system, by a) authenticating the user by verifying identification and validation responses presented by the user at a computing device; b) transmitting a passcode to the authenticated user; c) providing a digital agreement document associated with the financing product for display to the authenticated user at the computing device; d) verifying a passcode entered by the user to electronically sign the digital agreement document, against the transmitted passcode; and e) if the entered passcode is verified, registering an approved financing product for the user in the electronic financing system.

Description

System and Method for Digital Document Management Field of the Invention [0001] This invention relates to a digital document management method and system, and particularly to secure processing of an electronic application for a financial loan or credit account, and management of digital documents associated with the application process.
Background of the Invention [0002] A financial loan or line of credit may be issued to a customer by a bank or other financial institution, subject to identification verification and risk assessment of the customer applying for the loan or credit, and documented acceptance of the terms and conditions of an agreed loan or credit. Typically, applications for such financial loans are paper-based in order for the financial institution to perform the required checks and analysis.

[0003] Previously customers shopping online would have had to print off and sign a paper document pack in the home at point of acceptance. The document pack is large and complicated, and the loan application process is highly prone to errors, for example as customers complete the required documentation incorrectly and post the wrong pages back to the loan issuer.

[0004] Additionally, as the customer is not face to face with an administrator, a loan issuer would typically require the customer to provide a form of identification by post, for example to prove the customer's address, before the agreement is activated and the retail partner despatched goods. This gives rise to a risk for the customer as they have to send official and important paper documents in the public postal mail system. Invariably, the customer would send inappropriate documents or copies which were unacceptable. These errors increase the overall processing time and costs, and impact the delayed fulfilment of the customer order significantly.

[0005] There were additional problems with this typical route. Because there is no face to face interaction via this route, fraudsters would often apply via this method.
To satisfy the loan issuer's identification requirement, fraudsters would send supporting, fraudulent ID. This fraudulent ID was often of very high quality and difficult for back office process owners to spot thus increasing process time and causing additional risk exposure to the loan issuer, customers and clients.

[0006] What is needed is a more efficient and secure system for processing online applications for financial loans and credit.
Summary of the Invention [0007] According to one aspect of the present invention, there is provided a method and system for processing an application for a financing product for a user in an electronic financing system, by a) authenticating the user by verifying identification and validation responses presented by the user at a computing device; b) transmitting a passcode to the authenticated user; c) providing a digital agreement document associated with the financing product for display to the authenticated user at the computing device; d) verifying a passcode entered by the user to electronically sign the digital agreement document, against the transmitted passcode; and e) if the entered passcode is verified, registering an approved financing product for the user in the electronic financing system.

[0008] In a further aspect of the present invention authentication of the user in the application process is performed by receiving information presented by the user at a computing terminal; retrieving secured details associated with the user from a bureau database; generating at least one user validation question based on the retrieved secured details; receiving a response to the at least one generated user validation question presented by the user at the computing terminal; and verifying the received response against the retrieved secured details to authenticate the user.

[0009] In one embodiment, the process of verifying the identity of a customer applying for a loan relies on the inherent security provided by utilising customer data retrieved from a bureau database, and hence known only to the customer, together with the secure transmission of the loan application documents as a digital document pack to the customer's terminal or device.

[0010] According to another aspect of the invention, there is provided a method and system for securely receiving electronically signed digital documentation indicative of acceptance of terms and conditions associated with an issued financing product.

[0011] In one embodiment, the application process is conducted through a web browser interface of the customer terminal or device. In another embodiment, software is loaded on the customer's device to enable the customer to both apply for and activate an approved loan from their device, using an authentication token transmitted to the customer via a separate communication channel.

[0012] In yet a further aspect of the present invention there is provided a computing device, an online loan application system, and associated computer programs arranged to carry out the above method.
Brief Description of the Drawings [0013] There now follows, by way of example only, a detailed description of embodiments of the present invention, with references to the figures identified below.
Figure 1 is a block diagram showing the main components of a financing system according to an embodiment of the invention;
Figure 2 is a flow diagram of a loan application process in an embodiment of the invention.
Figure 3 is a diagram of an example of a computer system on which one or more of the functions of the embodiment may be implemented.
Detailed Description of Embodiments of the Invention Technical Architecture [0014] Referring to Figure 1, a financing system 1 according to an embodiment of the invention comprises a customer terminal 3 communicating over a data network 5 with a merchant system 7 and a loan issuer system 9. The customer terminal 3 is of a type that is known per se, such as a personal computer, laptop, computing terminal or the like, or a mobile smartphone such as an iPhoneTM, Blackberrr or AndroidTm smartphone. In this embodiment, the customer terminal 3 runs a web browser application 3a and provides for user interaction through a display 11 and a user input interface 13 such as a touch screen, touch pad, mouse, stylus or the like. In other embodiments, the computing terminal 3 may run a dedicated financing application issued by the merchant system 7 or the loan issuer system 9. It will be appreciated that the customer terminal 3 is merely an example of a potentially large number of computing devices operable within the system.

[0015] The data network 5 may be any suitable data communication network such as a mobile network, wireless network, a local- or wide-area network including a corporate intranet or the Internet, for example.
The customer terminal 3 communicates with the merchant system 7 via the data network 5 using communication protocols of a type that are known per se in data networks, for example TCP/IP, GPRS, EDGE or 3G protocols, and need not be described further.

[0016] The merchant system 7 includes a merchant online shop module 7a and a merchant database 7b that provide a merchant website for display by the customer terminal 3, for example through the web browser application 3a or any other suitable application. The merchant database 7b can also store data associated with customers registered with the merchant, such as names, contact details, addresses, payment card or account details, etc. An accounting and billing module 7c can also be provided to handle the associated payment transactions from sender to recipient funding accounts. Such retailer web sites hosted on a web server which are well known per se and need not be described further. In this embodiment, the merchant system 7 also manages a loan application module 15 providing an online loan application that is transmitted to the customer terminal 3. The online loan application can be an online web-based form of a type that is known per se and need not be described further.

[0017] The loan application module 15 can be provided by the associated loan issuer system 9. The loan application module 15 processes user input received from the customer terminal 3 as the user is completing the online application, including information such as legal name, home address, date of birth, e-mail address and the like. The loan application module 15 can authenticate the user based on received user responses to an integrated identification process using an Identification and Verification (INN) question generator 15a. In one embodiment, the !MN question generator 15a generates questions based on customer details 17a associated with the user that are retrieved from an external bureau database 17. The bureau 5 database 17 can securely store customer bureau details 17a, such as current banking and lending information associated with the individual customer, and voters roll validation information for the customer which will include present and past residential addresses of record.

[0018] It will be appreciated that these examples are provided merely to illustrate the types of customer bureau data 17a that can be provided to the system, and other types of bureau data are available that relate to information which is inherently known to the customer but not by a potential fraudster. The bureau database 17 can be securely hosted by a third party credit bureau that collects and collates personal information, financial data, and alternative data on individuals from a variety of data sources with which the bureaus have a relationship.

[0019] The loan application module 15 also manages transmission of a digital agreement document 15b to the customer terminal 3, the digital agreement document 15b including the terms and conditions that are associated with the loan.
The loan application module 15 also manages transmission of a passcode generated by a passcode generator 15c, for example by an e-mail to the customer. The received passcode is used by the customer to electronically sign the digital agreement document 15b at the customer terminal 3, to immediately indicate acceptance of the stated terms and conditions associated with the loan. The loan application module 15 receives the electronically signed digital agreement document 15b and can then notify the loan issuer system 9 of the approved and agreed loan via the data network 5. The loan issuer system 9 can store data associated with all approved and agreed loans in a database of activated loans 9a.

[0020] The merchant online shop system 7a, merchant database 7b, loan application system 15 and accounting and billing system 7c may be in operative communication with each other via, for example, a bus or any other subsystem that may transfer data between components and modules in the merchant system 7.
Loan Application Processing and Digital Agreement Document Handling [0021] An example of a process of processing an application for a financial product, such as a monetary loan or credit based funding account, for a customer will now be described, to illustrate the technical advantage of the financing system embodiment described above. Although the example is given in the context of applying for a financial loan issued by a loan issuer, it will be appreciated that the loan application module 15 can be adapted to process an online application for any other form of financial product, such as a credit card account or the like.

[0022] Figure 2 shows a flow diagram of the process of processing an online application for a loan and handling of the digital agreement document in a secure and efficient manner. For example, a customer at a merchant retailer online web site may be prompted to apply for financing to complete a purchase by clicking on a web link at the check-out stage of the online purchase transaction. In response to the customer providing user input to start the online loan application process, the merchant online shop module 7a passes control to the loan application module 15 to provide the online application for a financial product to the customer terminal 3.

[0023] The loan application process begins at 52-1 where the loan application module 15 receives user input to apply for a loan via the online application.
In response, the loan application module 15 processes a new online loan application for the customer at step S2-3, for example by providing an online form through a sequence of web pages to prompt the user to input personal information such as legal name, home address, date of birth, e-mail address, and the like. The user input information is transmitted back to loan application module 15. In one embodiment, the customer data stored in the merchant database 7b can be provided by the merchant online shop module 7a to the loan application module 15 to populate respective fields of the online application. In this way, the customer can complete the online application by providing any missing data or information.

[0024] As mentioned above, a user identification and verification (ID&V) process is integrated with the loan application process. The integrated user ID&V process begins at step S2-5 where the loan application module 15 communicates with the bureau database 17 to retrieve bureau data 17a associated with the customer.
At step S2-7, the ID&V question generator 15a uses the retrieved bureau customer data 17a to automatically generate a predefined number of questions for automated identification and verification of the customer. The number of questions that are generated for ID&V of a particular customer can depend on risk factors determined by the loan application module 15. As an example, five multiple choice questions can be generated by the ID&V question generator 15a for a typical customer that raises no high risk factors.

[0025] The questions are based on the bureau customer data 17a retrieved from the bureau database 17, which can be transmitted in a predefined format to identify the available information for that customer, such as his or her current banking and lending information, and present and past residential addresses of record. The ID&V
question generator 15a may store a database of template questions associated with different types of information retrieved from the bureau database 17, and the automatically generated ID&V questions may be of a form such as "When did you move into your current address?" or "You have a direct debit of 200 pounds leaving your account each month. Who is this to?". At step S2-9, the loan application module 15 provides the generated questions as the integrated ID&V process for the online loan application.

[0026] It will be appreciated that the loan application module 15 may carry out further steps of assessing whether a loan can be issued to the customer, as known per se and need not be described further. It will also be appreciated that when the loan application module 15 is unable to retrieve customer data from the bureau database 17, or if insufficient customer data is available from the bureau database 17 for the ID&V question generator 15a to generate a required number of questions, then the loan application module 15 can be configured to decline the online loan application and notify the customer accordingly. Alternatively, the loan application module 15 can proceed with the loan application in a conventional manner, for example transmitting the digital agreement documents 15b to the customer terminal with instructions to print the documents, physically sign the documents, and post the wet-signed documents back to the loan issuer.

[0027] Returning back to step S2-11, the loan application module 15 receives the user responses to the automatically generated ID&V questions and verifies that the customer's identity is authenticated by comparing the received responses to the customer data from the bureau database 17. The loan application module 15 can then provide a "Accept Decision" web page for display to the customer indicating that the loan application has been accepted and approved, and prompting the customer to download and view a digital agreement document 15b associated with the approved loan.

[0028] After verifying the customer's identity, the passcode generator 15c generates a passcode at step S2-15 that will be used by the customer to electronically sign the digital agreement document 15b associated with the loan. The generated passcode can be a numeric code of a predefined length, for example a six digit numeric passcode. Alternatively, any other form of passcode can be generated, such as a numeric, alphabetic, alphanumeric or non-alphanumeric symbols of predefined or varying lengths. At step S2-17, the loan application module 15 transmits a confirmation message to the customer, for example as an e-mail to the customer's email address. The e-mail confirmation message includes the passcode that is generated by the passcode generator 15c.

[0029] At step S2-19, the loan application module 15 transmits the digital agreement document 15b to the customer terminal 3, for example in response to user input when prompted by the ""Accept Decision" web page. The digital agreement document 15b can be generated by the loan application module 15 to include details of the accepted loan and the associated terms and conditions that the customer must acknowledge before the loan is actually issued. The loan application module 15 can provide the digital agreement document 15b in any form, such as a sequence of document pages for display by the browser application 3a of the computer terminal 3, or as a single digital document that is downloaded to the computer terminal 3 for viewing in a document reader application.

[0030] At step S2-21, the customer is prompted at the computer terminal 3 to input the received passcode as an electronic signature to indicate that he or she has reviewed the digital agreement document 15b and is accepting the stated terms and conditions. The user input passcode is received by the loan application module 15 at step S2-23 as the electronic signature from the customer. In response, the loan application module 15 can store the customer's digital agreement document 15b as a non-editable electronically signed digital document, for example by adding the date of receiving the passcode as the electronic signature, text indicating that the document was electronically signed, and information identifying the customer terminal 3 from which the electronic signature was received, such as the IP
address of the customer terminal 3. At step S2-25, the loan application module 15 can transmit the electronically signed digital agreement document 15b to the loan issuer system 9 for storage in the database of activated loans 9a. The online application can also provide a final web page to the customer to indicate that the electronic signature was accepted and presenting a link for the customer to download a copy of the non-editable electronically signed digital agreement document.
Advantages [0031] A number of advantages will be understood from the above description of the embodiments of the present invention.

[0032] In particular, the use of a passcode to electronically sign the digital agreement documents is advantageous, as it allows the loan issuer to complete a paperless application process via a client web-store from wing to wing, and enables assured acknowledgement and delivery of signed agreement documentation to be instant.

[0033] Additionally, the online loan application process includes an integrated challenge question based identification and verification process that efficiently determines that a customer is authenticated before allowing the customer to progress to e-signing of their agreement with no need for paper copies to be posted or wet signature to be captured.

[0034] Moreover, as the new identification and verification process generates ID&V
questions for the customer which are gleaned from the customer's current bureau, a 5 loan issuer is assured that the customer is authenticated (i.e. applicant is who they say they are) when the customer achieves an acceptable pass rate. This integrated identification and verification process negates the requirement for supporting ID and reduces the chance of fraud attacks from online applications for financial products.
10 Computer Systems [0035] The entities described herein, such as the merchant system and the loan application module, and their respective constituent modules and components, may be implemented by computer systems such as computer system 1000 as shown in Figure 3. Embodiments of the present invention may be implemented as programmable code for execution by such computer systems 1000. After reading this description, it will become apparent to a person skilled in the art how to implement the invention using other computer systems and/or computer architectures.

[0036] Computer system 1000 includes one or more processors, such as processor 1004. Processor 1004 may be any type of processor, including but not limited to a special purpose or a general-purpose digital signal processor. Processor 1004 is connected to a communication infrastructure 1006 (for example, a bus or network).
Various software implementations are described in terms of this exemplary computer system. After reading this description, it will become apparent to a person skilled in the art how to implement the invention using other computer systems and/or computer architectures.

[0037] Computer system 1000 also includes a main memory 1008, preferably random access memory (RAM), and may also include a secondary memory 610. Secondary memory 1010 may include, for example, a hard disk drive 1012 and/or a removable storage drive 1014, representing a floppy disk drive, a magnetic tape drive, an optical disk drive, etc. Removable storage drive 1014 reads from and/or writes to a removable storage unit 1018 in a well-known manner. Removable storage unit represents a floppy disk, magnetic tape, optical disk, etc., which is read by and written to by removable storage drive 1014. As will be appreciated, removable storage unit 618 includes a computer usable storage medium having stored therein computer software and/or data.

[0038] In alternative implementations, secondary memory 1010 may include other similar means for allowing computer programs or other instructions to be loaded into computer system 1000. Such means may include, for example, a removable storage unit 1022 and an interface 1020. Examples of such means may include a program cartridge and cartridge interface (such as that previously found in video game devices), a removable memory chip (such as an EPROM, or PROM, or flash memory) and associated socket, and other removable storage units 1022 and interfaces which allow software and data to be transferred from removable storage unit 1022 to computer system 1000. Alternatively, the program may be executed and/or the data accessed from the removable storage unit 1022, using the processor 1004 of the computer system 1000.

[0039] Computer system 1000 may also include a communication interface 1024.
Communication interface 1024 allows software and data to be transferred between computer system 1000 and external devices. Examples of communication interface 1024 may include a modem, a network interface (such as an Ethernet card), a communication port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, etc. Software and data transferred via communication interface 1024 are in the form of signals 1028, which may be electronic, electromagnetic, optical, or other signals capable of being received by communication interface 1024. These signals 1028 are provided to communication interface 1024 via a communication path 1026. Communication path 1026 carries signals 1028 and may be implemented using wire or cable, fibre optics, a phone line, a wireless link, a cellular phone link, a radio frequency link, or any other suitable communication channel. For instance, communication path 1026 may be implemented using a combination of channels.

[0040] The terms "computer program medium" and "computer usable medium" are used generally to refer to media such as removable storage drive 1014, a hard disk installed in hard disk drive 1012, and signals 1028. These computer program products are means for providing software to computer system 1000. However, these terms may also include signals (such as electrical, optical or electromagnetic signals) that embody the computer program disclosed herein.

[0041] Computer programs (also called computer control logic) are stored in main memory 1008 and/or secondary memory 1010. Computer programs may also be received via communication interface 1024. Such computer programs, when executed, enable computer system 1000 to implement embodiments of the present invention as discussed herein. Accordingly, such computer programs represent controllers of computer system 1000. Where the embodiment is implemented using software, the software may be stored in a computer program product and loaded into computer system 1000 using removable storage drive 1014, hard disk drive 1012, or communication interface 1024, to provide some examples.

[0042] Alternative embodiments may be implemented as control logic in hardware, firmware, or software or any combination thereof.
Alternative Embodiments [0043] The above embodiments are described by way of example, and alternative embodiments which may become apparent to the skilled person on reading the above description may nevertheless fall within the scope of the claims.

[0044] For example, in the embodiment described above, the customer is prompted to provide the received passcode as an electronic signature to indicate that he or she has reviewed the digital agreement document and is accepting the stated terms and conditions. As those skilled in the art will appreciate, the online application may provide an alternative option for the customer to instead download, print, sign and post a paper copy of the agreement document to the loan issuer, to complete the loan application process in the traditional, less efficient, manner.

[0045] In a further alternative embodiment, after the customer has been authenticated by the integrated challenge question identification and verification process, the customer may be prompted to digitally sign a received digital agreement document using an input interface of the customer terminal that supports direct input of the customer's signature, for example using his or her finger or a stylus.

[0046] In the embodiment above, a predefined number of ID&V questions are automatically generated based on customer details retrieved from a bureau database, and the customer is authenticated after verifying that he or she has responded with correct answers to all of the generated questions. As those skilled in the art will appreciate, due to the automated nature of the question generation, the loan application module could instead be configured to verify a customer's identity when a predefined or threshold number of the ID&V questions have been answered correctly. For example, the system can determine that a customer is authenticated when he or she answers a minimum of three out of five ID&V questions correct and thus allow the customer to progress to e-signing of their digital agreement document.

[0047] Although not illustrated, it will be appreciated that when the loan application module is unable to verify the identity of the customer, for example if the customer does not correctly answer all of the generated ID&V questions, then the customer is not authenticated to the system and the loan application will be declined.
Additionally, even after the customer is authenticated by the integrated ID&V
challenge question process, the loan application module may determine that the customer is not eligible for a loan for other reasons. A decline message can be transmitted to the customer terminal, and the message can include the reason for the decline decision.

[0048] In the embodiment described above, the loan application module is provided by the loan issuer system and managed by the merchant system. As those skilled in the art will appreciate, the loan issuer system may instead host and manage a loan application module, and communicate with the merchant system to handle requests for new financial products.

[0049] It will also be appreciated that some of the process steps described in the embodiment above may proceed in various orders and that the particular order shown in Figure 2 is for illustrative purposes according to one exemplary embodiment of said steps. For example, the online loan application module may be arranged to generate and transmit a passcode to the customer by e-mail at an earlier stage of the application process.

[0050] As a further modification, the loan application module may instead be configured to pass the received user details from the online application to the loan issuer system, and the loan issuer system can instead verify the identity of the applicant customer and determine whether he or she is eligible for the financial product subsequently register and activate the approved financial product.

Claims (13)

1. A computer-implemented method of processing an application for a financing product for a user in an electronic financing system, the method comprising:
a) authenticating the user by verifying identification and validation responses presented by the user at a computing device;
b) transmitting a passcode to the authenticated user;
c) providing a digital agreement document associated with the financing product for display to the authenticated user at the computing device;
d) verifying a passcode entered by the user to electronically sign the digital agreement document, against the transmitted passcode; and e) if the entered passcode is verified, registering an approved financing product for the user in the electronic financing system.

2. The method of claim 1, wherein the authentication step comprises:
a1) receiving information presented by the user at a computing terminal to complete the application for the financing product;
a2) retrieving additional details associated with the user from a bureau database;
a3) generating at least one user validation question based on the retrieved additional details;
a4) receiving a response to the at least one generated user validation question presented by the user at the computing terminal; and a5) verifying the received response against the retrieved additional details to authenticate the user.

3. The method of claim 2, wherein the retrieved secured details are not transmitted to the user at the computing terminal.

4. The method of claim 2, wherein the number of generated validation questions is based on a determined level of security associated with the user.

5. The method of claim 1, wherein the passcode is transmitted to the user by e-mail.

6. The method of claim 1, wherein the passcode is entered by the user at the computing device to electronically sign the digital agreement document.

7. The method of claim 1, wherein the passcode comprises numeric, alphabetic, alphanumeric or non-alphanumeric symbols.

8. The method of claim 1, wherein the financing product is a monetary loan or a credit based payment account.

9. The method of claim 1, wherein the digital agreement document comprises terms and conditions associated with the financing product.

10. The method of claim 9, wherein the user electronically signs the digital document to indicate acceptance of the terms and conditions.

11. A system for processing an application for a financing product for a user, comprising:
a) an authenticator operable to authenticate the user by verifying identification and validation responses presented by the user at a computing device;
b) a passcode transmitter operable to transmit a passcode to the authenticated user;
c) a digital document provider operable to provide a digital agreement document associated with the financing product for display to the authenticated user at the computing device;

d) a passcode verifier operable to verify a passcode entered by the user to electronically sign the digital agreement document, against the transmitted passcode;
and e) an approver operable to register an approved financing product for the user in the electronic financing system when the entered passcode is verified.

12. The system of claim 11, wherein the authenticator is operable to authenticate the user by:
a1) receiving information presented by the user at a computing terminal;
a2) retrieving secured details associated with the user from a bureau database;
a3) generating at least one user validation question based on the retrieved secured details;
a4) receiving a response to the at least one generated user validation question presented by the user at the computing terminal; and a5) verifying the received response against the retrieved secured details to authenticate the user.

13. A non-transitory computer-readable medium comprising computer-executable instructions, that when executed perform the method of:
a) authenticating the user by verifying identification and validation responses presented by the user at a computing device;
b) transmitting a passcode to the authenticated user;
c) providing a digital agreement document associated with the financing product for display to the authenticated user at the computing device;
d) verifying a passcode entered by the user to electronically sign the digital agreement document, against the transmitted passcode; and e) if the entered passcode is verified, registering an approved financing product for the user in the electronic financing system.