254 may be an individual, such as a banker, who assists customers setting up new accounts with the provider institution (e.g., a branch banker, a branch manager, provider institution representative, etc.). The customer device 104 and the provider agent device 254 can include any type of computing device that may be used to create, access, and/or modify account information of accounts relating to the customer. In this regard, the customer device 104 and the provider agent device 254 may include any wearable or non-wearable device. Wearable devices refer to any type of device that an individual wears including, but not limited to, a watch (e.g., a smart watch), glasses (e.g., eyeglasses, sunglasses, smart glasses, etc.), bracelet (e.g., a smart bracelet), etc. The customer device 104 and the provider agent device 254 may also include any type of computing device including, but not limited to, a phone (e.g., smartphone), a tablet, a laptop, a desktop computer, a personal digital assistant, etc. The customer device 104 and the provider agent device 254 may include the same computing devices (e.g., the customer device 104 is a tablet and the provider agent device 254 is a tablet). Alternatively, the customer device 104 and the provider agent device 254 may include different computing devices (e.g., the customer device 104 is a phone and the provider agent device 254 is a laptop).

In some embodiments, the customer utilizes the customer device 104 to receive or capture a first code, send preliminary account application information, and send a second code to the provider institution computing system 106. In some embodiments, the customer utilizes the customer device 104 to receive account application instructions, receive authentication instructions, complete an account application, and access account information that is stored and/or otherwise managed by the provider institution computing system 106.

As shown in FIG. 1, the customer device 104 can include a network interface circuit 124 enabling the customer device 104 to exchange information over the network 108, a processing circuit 126, and an input/output (I/O) device 136. The network interface circuit 124 can include program logic that facilitates connection of the customer device 104 to the network 108. The network interface circuit 124 can support communication between the customer device 104 and other systems. For example, the network interface circuit 124 can include a cellular modem, a Bluetooth transceiver, a Bluetooth beacon, a radio-frequency identification (RFID) transceiver, and a near-field communication (NFC) transmitter. In some embodiments, the network interface circuit 124 includes the hardware and machine-readable media sufficient to support communication over multiple channels of data communication. Further, in some embodiments, the network interface circuit 124 includes cryptography capabilities to establish a secure or relatively secure communication session between the customer device 104 and provider institution computing system 106. In this regard, information (e.g., account information, login information, financial data, and/or other types of data) may be encrypted and transmitted to prevent or substantially reduce the threat of hacking.

The processing circuit 126 is shown to include a processor 128 and a memory 130. The processor 128 may be implemented as one or more application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), a group of processing components, or other suitable electronic processing components. The memory 130 may be one or more devices (e.g., RAM, ROM, Flash memory, hard disk storage) for storing data and/or computer code for completing and/or facilitating the various processes described herein. The memory 130 may be or include non-transient volatile memory, non-volatile memory, and non-transitory computer storage media. The memory 130 may include database components, object code components, script components, or any other type of information structure for supporting the various activities and information structures described herein. The memory 130 may be communicably coupled to the processor 128 and include computer code or instructions for executing one or more processes described herein.

The customer device 104 is shown to include a client application 132. The client application 132 is configured to facilitate management of customer accounts on the customer device 104 and allow the first customer to interact with the customer's accounts. In some embodiments, the client application 132 is structured to provide displays to the customer device 104 (e.g., to the I/O device 136 described below) that enable the customer to view and/or manage customer accounts. Accordingly, the client application 132 can be configured to send information to, and receive information from, the provider institution computing system 106. In some embodiments, the client application 132 may be an application (e.g., a mobile banking application, a social media application, a mobile wallet application, etc.) for the customer to interact with. The client application 132 may couple to a website via the network. The client application 132 may include a mobile banking application and/or a web browser. For example, the client application 132 may be a mobile banking application or other provider institution application or a web browser application.

In some embodiments, the client application 132 may be incorporated with an existing application in use by the provider institution computing system 106 (e.g., a mobile banking application, a service provider application, etc.). In other embodiments, the client application 132 is a separate software application implemented on the customer device 104. The client application 132 may be downloaded by the customer device 104 prior to its usage, hard coded into the memory 130 of the customer device 104, or be a network-based or web-based interface application such that the customer device 104 may provide a web browser to access the application, which may be executed remotely from the customer device 104. Accordingly, the customer device 104 may include software and/or hardware capable of implementing a network-based or web-based application. For example, in some instances, the client application 132 includes software such as HTML, XML, WML, SGML, PHP (Hypertext Preprocessor), CGI, and like languages.

In the latter instance, the customer (e.g., a customer or potential customer) may have to log onto or access the web-based interface before usage of the application. Further, and in this regard, the client application 132 may be supported by a separate computing system including one or more servers, processors, network interface circuits, etc. that transmit applications for use to the customer device 104.

In certain embodiments, the client application 132 includes an application programming interface (API) and/or a software development kit (SDK) that facilitate the integration of other applications with the client application 132. For example, in some embodiments, the client application 132 is configured to utilize the functionality of the provider institution computing system 106 through an API.

The client application 132 enables a customer to send account information and access account information tied to customer accounts associated with the customer. As described above, the client application 132 can be provided as an application on the customer device 104. For example, the client application 132 may be implemented as a banking application associated with a provider institution (e.g., that operates the provider institution computing system 106) and allows the customer to access a checking account, a savings account, loan/mortgage information, etc. In some embodiments, the client application 132 constitutes a web browser hard coded into the memory 130 and includes executable instructions that allow the customer device 104 to communicate with various systems (e.g., the provider institution computing system 106) via a communications protocol (e.g., the HTTP protocol).

In some embodiments, the customer interacts with the client application 132 via an I/O device 136. The I/O device 136 can include hardware and associated logics that enable the customer to exchange information with the customer device 104. An input component of the I/O device 136 can allow the customer to provide information to the customer device 104. The input component may include various hardware and associated logics such as, for example, a mechanical keyboard, a mechanical mouse, a touchscreen, a microphone, a camera, a fingerprint scanner, etc. Likewise, an output component of I/O device 136 can include hardware and associated logics that allow the customer device 104 to provide information to the customer. For example, the output component may include a digital display, a speaker, illuminating icons, LEDs, etc. In this way, the customer can interact with the client application 132. For example, the customer may provide login information (e.g., customer name, password, etc.) by typing on a mechanical keyboard or touchscreen keyboard included in the I/O device 136 and be provided account information on a digital display component of the I/O device 136.

As shown in FIG. 1, the provider agent device 254 can include a network interface circuit 224 enabling the provider agent device 254 to exchange information over the network 108, a processing circuit 226, and an input/output (I/O) device 236. The network interface circuit 224 can include program logic that facilitates connection of the provider agent device 254 to the network 108. The network interface circuit 224 can support communication between the provider agent device 254 and other systems such as the provider institution computing system 106 and the customer device 104. For example, the network interface circuit 224 can include a cellular modem, a Bluetooth transceiver, a Bluetooth beacon, a radio-frequency identification (RFID) transceiver, and a near-field communication (NFC) transmitter. In some embodiments, the network interface circuit 224 includes the hardware and machine-readable media sufficient to support communication over multiple channels of data communication. Further, in some embodiments, the network interface circuit 224 includes cryptography capabilities to establish a secure or relatively secure communication session between the provider agent device 254 and the provider institution computing system 106. In this regard, information (e.g., account information, login information, financial data, and/or other types of data) may be encrypted and transmitted to prevent or substantially prevent a threat of hacking.

The processing circuit 226 is shown to include a processor 228 and a memory 230. The processor 228 may be implemented as one or more application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), a group of processing components, or other suitable electronic processing components. The memory 230 may be one or more devices (e.g., RAM, ROM, Flash memory, hard disk storage) for storing data and/or computer code for completing and/or facilitating the various processes described herein. The memory 230 may be or include non-transient volatile memory, non-volatile memory, and non-transitory computer storage media. The memory 230 may include database components, object code components, script components, or any other type of information structure for supporting the various activities and information structures described herein. The memory 230 may be communicably coupled to the processor 228 and include computer code or instructions for executing one or more processes described herein.

The provider agent device 254 is shown to include a provider application 232. The provider application 232 is configured to facilitate management of customer accounts by an agent of the provider institution of a provider institution. In some embodiments, the provider application 232 is structured to provide displays to the provider agent device 254 (e.g., to the I/O device 236 described below) that enable the agent of the provider institution to view and/or manage customer accounts. Accordingly, the provider application 232 can be configured to send information to and receive information from the provider institution computing system 106. In some embodiments, the provider application 232 may provide an application (e.g., a mobile banking application, a social media application, a mobile wallet application, an account management application, etc.) for the agent of the provider institution to interact with various customers and the accounts associated with the customers.

In some embodiments, the provider application 232 may be incorporated with an existing application in use by the provider institution computing system 106 (e.g., a service provider application, etc.). In other embodiments, the provider application 232 is a separate software application implemented on the provider institution computing system 106. The provider application 232 may be downloaded by the provider institution computing system 106 prior to its usage, hard coded into the memory 230 of the provider institution computing system 106, or be a network-based or web-based interface application such that the provider institution computing system 106 may provide a web browser to access the application, which may be executed remotely from the provider institution computing system 106. Accordingly, the provider institution computing system 106 may include software and/or hardware capable of implementing a network-based or web-based application. For example, in some instances, the provider application 232 includes software such as HTML, XML, WML, SGML, PHP (Hypertext Preprocessor), CGI, and like languages.

In the latter instance, the agent (e.g., an employee of the provider institution) may have to log onto or access the web-based interface before usage of the application. Further, and in this regard, the provider application 232 may be supported by a separate computing system including one or more servers, processors, network interface circuits, etc. that transmit applications for use to the provider institution computing system 106.

In certain embodiments, the provider application 232 includes an application programming interface (API) and/or a software development kit (SDK) that facilitate the integration of other applications with the provider application 232. For example, in some embodiments, the provider application 232 is configured to utilize the functionality of the provider institution computing system 106 through an API.

The provider application 232 can allow an agent (e.g., an agent of the provider institution) of the provider institution to access account information tied to customer accounts associated with the various customer. As described above, the provider application 232 can be implemented as an application on the provider agent device 254. For example, the provider application 232 may be implemented as a banking application associated with a provider institution (e.g., that operates the provider institution computing system 106) and allows the agent of the provider institution to access information associate with various customers, such as checking accounts, savings accounts, loan/mortgage information, credit scores, etc. The provider application 232 may be implemented as an entity application associated with the entity (e.g., that operates the provider agent device 254) and allows the agent of the provider institution to access accounts associated with various customers such as checking accounts, savings accounts, etc. In some embodiments, the provider application 232 constitutes a web browser hard coded into the memory 230 and includes executable instructions that allow the provider agent device 254 to communicate with various systems (e.g., the provider institution computing system 106) via a communications protocol (e.g., the HTTP protocol).

In some embodiments, the agent of the provider institution interacts with the provider application 232 via an I/O device 236. The I/O device 236 can include hardware and associated logics that enable the agent of the provider institution to exchange information with the provider agent device 254. An input component of the I/O device 236 can allow the agent of the provider institution to provide information to the provider agent device 254. The input component may include various hardware and associated logics such as, for example, a mechanical keyboard, a mechanical mouse, a touchscreen, a microphone, a camera, a fingerprint scanner, etc. Likewise, an output component of I/O device 236 can include hardware and associated logics that allow the provider agent device 254 to provide information to the agent of the provider institution. For example, the output component may include a digital display, a speaker, illuminating icons, LEDs, etc. In this way, the agent of the provider institution can interact with the provider application 232. For example, the agent of the provider institution may provide login information (e.g., customer name, password, etc.) by typing on a mechanical keyboard of the I/O device 236 and be provided account information on a digital display component of the I/O device 236.

As shown in FIG. 1, digital banker application system 100 includes a provider institution computing system 106. In some embodiments, digital banker application system 100 includes multiple provider institution computing system 106s 106. The provider institution computing system 106 is associated with a provider institution (e.g., a financial institution such as a bank, credit union, credit card company, or another entity) and is operated and maintained by the provider institution.

The provider institution computing system 106 is shown to include a network interface circuit 138 and a processing circuit 140. As shown, the provider institution computing system 106 a processing circuit 140 and a network interface circuit 138 enabling the provider institution computing system 106 to exchange information over the network 108. In some embodiments, the network interface circuit 138 and the processing circuit 140 are similar to and/or the same as the network interface circuit 124 and the processing circuit 126 of the customer device 104, respectively. The network interface circuit 138 can include program logic that facilitates connection of the provider institution computing system 106 to the network 108. The network interface circuit 138 can support communication between the other provider institution computing systems 106 and other systems, such as the customer device 104, the provider agent device 254, and/or any third-party computing systems. For example, the network interface circuit 138 can include a cellular modem, a Bluetooth transceiver, a Bluetooth beacon, a radio-frequency identification (RFID) transceiver, and a near-field communication (NFC) transmitter. In some embodiments, the network interface circuit 138 includes the hardware and machine-readable media sufficient to support communication over multiple channels of data communication. Further, in some embodiments, the network interface circuit 138 includes cryptography capabilities to establish a secure or relatively secure communication session between other systems such as the customer device 104, the provider agent device 254, and/or any third-party computing system. In this regard, information (e.g., account information, login information, financial data, and/or other types of data) may be encrypted and transmitted to prevent or substantially prevent a threat of hacking.

The processing circuit 140 is shown to include a processor 114 and a memory 116. The processor 114 may be implemented as one or more application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), a group of processing components, or other suitable electronic processing components. The memory 116 may be one or more devices (e.g., RAM, ROM, Flash memory, hard disk storage) for storing data and/or computer code for completing and/or facilitating the various processes described herein. The memory 116 may be or include non-transient volatile memory, non-volatile memory, and non-transitory computer storage media. The memory 116 may include database components, object code components, script components, or any other type of information structure for supporting the various activities and information structures described herein. The memory 116 may be communicably coupled to the processor 114 and include computer code or instructions for executing one or more processes described herein. In some embodiments, the provider institution computing system 106 is a distributed computing system. In this case, provider institution computing system 106 may include multiple network interface circuits 138 and/or multiple processing circuits 140.

The provider institution computing system 106 is shown to include a memory 144 that is shown to include an account database 146. In some embodiments, the processing circuit 140 can allow the provider institution computing system 106 to access and provide information stored in the account database 146. The account database 146 (and thereby the provider institution computing system 106) can operate as a source of data for account information in the digital banker application system 100. In general, the account database 146 can store data associated with customers and can retrieve said data in response to querying initiated by the processing circuit 140. In this way, if the provider agent device 254 and/or the customer device 104 institution requests account information from the provider institution computing system 106 that is stored in the account database 148, the processing circuit 140 can process the request to retrieve the information from the account database 148 and provide the information back (e.g., via the network 108).

Referring now to FIG. 2, a flow diagram of an account opening process 200 is shown according to an example embodiment. It should be appreciated the account opening process 200 may be performed in any order and that certain processes may be omitted. Reference may be made to the system and components of FIG. 1 to aid explanation of process 200.

At process 202, a first code is captured. For example, the first code may be captured by the customer device 104. In certain embodiments, account application instructions may be received by the customer device 104 in response to the first code being capture. The account application instructions may instruct or otherwise prompt the customer regarding how complete an account application. The account application instructions may be received from the provider institution computing system 106 and/or the provider agent device 254, as will be discussed in further detail below with respect to process 204. In one embodiment, account application instructions may be provided to a customer in conjunction with the first code. The account application instructions may instruct the customer how to use/access the first code to open an account.

For example, the agent of the provider institution may display written account application instructions on a poster, brochure, presentation, handout, digital display, etc. For example, the agent of the provider institution may display a poster at an account opening event. The poster may include the first code that is capable of being captured by a customer device 104 along with account application instructions that instruct the customer how to use/access the code to open an account. In one example embodiment, the account application instructions may instruct the customer to download an application (e.g., the client application 132). For example, the customer may utilize a camera, which may be accessible by the client application 132, on the customer device 104 to scan a QR code on the poster.

In another example, the account application instructions may instruct the customer to use an image capture device (e.g., a camera) on the customer device 104 to capture the first code. When the customer device 104 captures or scans the first code, a browser or a corresponding application (e.g., the client application 132) may be launched on the customer device 104. The first code may be embedded with code to cause launching or activation of the client application 132, which may be a specific application (e.g., a mobile banking application) or a web browser application. Alternatively, the first code may be a URL that, when entered into the customer device 104 launches a browser. The browser may display a website with additional account application instructions. Further, the browser may direct a customer to download an application (e.g., the client application 132 when it is embodied as a specific application and not the web browser) on the customer device 104.

In some embodiments, the first code may be a scannable code, such as a bar code, a QR code, a PDF417, Code 39, and a Codabar. For example, the customer device 104 may be used to scan the first code. In other embodiments, the first code may be a URL that can be captured by the customer device 104. For example, a customer may use the I/O device 136 to enter the URL into the customer device 104. Alternatively, the customer device 104 may be used to scan the URL. In other embodiments, the first code may be a sequence of alphanumeric characters that may be captured by the customer device 104. For example, a customer may use the I/O device 136 of the customer device 104 to enter the alphanumeric characters into the customer device 104. Alternatively, the customer device 104 may be used to scan the alphanumeric characters.

In some embodiments, the first code may be provided to a customer via a visual medium. For example, an agent of the provider institution may display the first code on a poster, brochure, presentation, handout, digital display, etc. Further, the first code may be generally displayed to members of the public. For example, the first code (e.g., a web address, application name, barcode, etc.) may be displayed on a poster, billboard, or other visual advertisement in public. A poster or digital display that includes the first code may also be displayed inside a local branch of the provider institution. In some embodiments, an agent of the provider institution may display a poster at a mixer. In some embodiments, the first code may be provided to the customer via an audio medium. For example, the agent of the provider institution may verbally read the first code, or otherwise provide the first code, to the first customer. Further, the provider institution may purchase advertisement time on a radio station and/or during a podcast and provide the first code to the customer.

In some embodiments, the first code may be provided to the first customer via a digital medium. For example, the agent of the provider institution may provide the first code to the customer device 104 in an email, text message, iMessage, etc. For example, the agent of the provider institution may email the first code to a group of customers at a mixer event. For example, if the mixer event is at a college campus, the agent may receive a list of students, along with each student's corresponding email address, and the agent may send an email to the group of students that includes account application instructions and/or the first code. In this case and rather than being a scannable, the first code may be configured as a URL. The URL may be unique (i.e., include unique identifiers) for the specific account opening event, as will be discussed further herein. When the customer selects the URL on the customer device 104, the client application 132 (e.g., a mobile banking application, a browser, etc.) may be launched on the customer device 104. For example, the browser may display a website with account application instructions. Further, the browser may direct a customer to download an application on the customer device 104, such as the client application 132. Further, the first code may be captured by the customer device 104 via NFC. For example, the first code may be stored on the provider agent device 254 and sent to the customer device 104 via NFC tap, such that the customer device 104 captures the first code. Using short-range wireless transmission protocols add security to the process and enable the process to be specific to event/limited to reduce bandwidth constraints.

The first code is structured to accelerate the account opening process 200. For example, by capturing the first code, a website or corresponding application (e.g., the client application 132) may be automatically launched on the customer device 104 so that a customer does not need to search for the proper website and/or corresponding application needed to begin an account application. As will be discussed further herein, unique identifiers embedded into the first code may accelerate the account application process because certain account application information may be automatically populated because of the unique identifiers. Further, the first code is structured to add a layer security and traceability. For example, as is discussed further herein, unique identifiers in the first code may identify the agent that is assisting the customer apply for an account. Further, the unique identifiers may be used to while verifying the second code, thereby adding an additional layer of security.

In certain embodiments, the client application 132 (e.g., a browser and/or a corresponding application), may be launched on the customer device 104 in response to the first code being captured. For example, when the first code is captured, a web browser may be launched, and the customer device 104 may be directed to a webpage. The web page may be operated by the provider institution. For example, the web page may be a virtual banking website. Further, an application, such as a mobile application, may be launched on the customer device 104 in response to the first code being captured. For example, a mobile banking application operated by the provider institution (e.g., the client application 132) may be launched on the customer device 104 in response to the first code being captured. Further, a request to download an application may be presented on the customer device 104 in response to the first code being captured on the customer device 104. For example, an application download platform (e.g., Apple App Store®, the Android Marketplace®, the Google Play® store, etc.) may be launched on the customer device 104 in response to the first code being captured. The customer may then be prompted to download the mobile banking application on the customer device 104. In some embodiments, the customer device may scan a QR code, which may launch an application download platform, which may prompt the customer to download a mobile banking application on the customer device 104, and once downloaded, the mobile banking application may be launched.

In some embodiments, process 202 may include identifying the location of the customer device 104. The customer device 104 may use a GPS, or other location identification method, to determine the location of the customer device 104. For example, the customer device 104 may use a GPS, or other location identification method, to identify the mixer event as well as the location or approximate location of the customer device 104. In some embodiments, the location of the customer device 104 may be used in conjunction with stored location information regarding the mixer. For example, when the customer device 10 is within a predefined range of a mixer, a prompt may be sent to the customer device 104 to capture the first code. Alternatively, the first code may be transmitted as a push notification to the customer device 104. In some embodiments, the first code may be transmitted as a push notification to a customer device 104 that is operated by a customer that is an existing customer with the provider institution such that the provider institution may provide the customer device 104 with additional products and/or services.

In certain embodiments, the first code may include unique identifiers. For example, the location, date, and/or time of an event may be embedded as unique identifiers within the first code. Further, the identity of an agent of the provider institution may be included as a unique identifier in the first code. In some embodiments, the customer may not be aware that this information is embedded within the first code. The unique identifiers may be used later in the account opening process 200. For example, when the second code is received by the provider institution computing system 106 from the customer device 104 (see process 214 below), the second code may include unique identifiers that may be compared to the unique identifiers in the first code as an added layer of security, as will be discussed further herein. Further, the unique identifier may be used to automatically generate preliminary account application information, as will be discussed further with respect to process 204 and process 206. Further, when the first code is captured by the customer device 104, the customer device 104 may use a GPS or other location identification method to determine a position of the customer device 104, and the location of the customer device 104 may be used as a unique identifier. The unique identifiers may be used later in the account opening process 200, as will be discussed further herein.

At process 204, account application instructions may be received. For example, account application instructions may be received by the customer device 104. In certain embodiments, account application instructions may be received by the customer device 104 in response to the first code being captured. For example, the account application instructions may be received from the provider institution computing system 106 and/or the provider agent device 254. The account application instructions may provide an indication of the information needed by a customer to complete the account application. As discussed above, the account application instructions may be provided to the customer before the first code is captured. In this example embodiment, the account application instructions may instruct the customer how to use/access the first code to open an account. Further, as discussed above, the account application instructions may be provided to the customer in conjunction with the first code. In this example embodiment, the account application instructions may instruct the customer how to use/access the first code to open an account.

The account opening instructions may be received by the customer device 104. For example, if a webpage or application (e.g., the client application 132) is launched in response to the first code being captured, the webpage or application may display account application instructions. In some embodiments, a graphical user interface (GUI) may be displayed on the customer device 104 in response to the first code being captured. The GUI may include account application instructions, such as the GUI shown in FIGS. 4 and 5, which are discussed further below. The account application instructions may include information such as the forms of identification that may be needed to open a new account, login information needed to create an account on the webpage or application, and a prompt that instructs the customer to fill in preliminary account application instructions within the webpage or application (see FIG. 5).

The account application instructions received by the customer, or group of customers, may include instructions to begin providing answers to questions needed to open a new account. For example, after the webpage or application (e.g., the client application 132) is launched on the customer device 104, the webpage or application may display via the I/O device 136 instructions for filling out preliminary account application information (e.g., name, address, type of account the customer would like to open, etc.) needed to open a new account with the provider institution.

In some embodiments, some of the preliminary account application information may be automatically filled in, at least partly, on behalf of the customer. For example, if the first code includes unique identifiers, certain preliminary account application information may be filled in for the customer automatically using the unique identifiers (i.e., one or more fields of the GUI may be pre-populated with information specific to the first code). For example, if the first code if the first code includes a unique identifier that identifies the location of a local branch, the location of the local branch may be automatically filled in for the customer in the preliminary account information. Similarly, if the first code is displayed at a mixer, the location of the nearest local branch may be automatically filled in. The customer may then use the I/O device 136 of the customer device 104 to complete the remainder of the preliminary account application information, as will be discussed below. Alternatively, or additionally, the customer may use the customer device 104 to upload a photograph or multiple photographs of a physical form of identification to the webpage or application (e.g., the client application 132). These photographs may then be scanned, and preliminary account application information may be pulled from the physical form of identification. This information may then be used to automatically fill part, or all of the preliminary account application information as will be discussed below.

Process 206 includes sending preliminary account application information (i.e., customer information). For example, the customer device 104 may send preliminary account application information to the provider institution computing system 106 and/or the provider agent device 254. The preliminary account application information may include information requested as a part of the account application instructions. The preliminary account application information may include information needed to open an account with the provider institution. For example, the preliminary account application information may include information required by the provider institution's CIP.

The preliminary account information may include information about the applicant (i.e., the customer) that is needed to open an account with the provider institution. Some or all of the preliminary information may also be required by the provider institution's CIP. For example, the preliminary information may include the customer's first name, middle name, last name, date of birth, address, city, state, and zip code. The preliminary account information may also include information about a form of identification the customer may wish to use to verify the customer's identity. For example, the preliminary account information may include the type of identification (e.g., passport, driver's license, birth certificate, student ID, credit card, debit card, insurance card, etc.) and the identification number (e.g., driver's license number, passport number, etc.).

The preliminary account information may also include a picture of a form, or multiple forms, of identification that the customer may use to verify the customer's identity. For example, the customer may take a picture of the front and back of his or her driver's license using the camera on the customer device 104. The customer may then send these pictures, along with the other preliminary account application information to the provider institution. The preliminary account information may also include a preferred local branch that the customer would like to select as the customer's branch. This information may be determined at least in part based on unique identifiers that are included in the first code or determined when the first code is captured. For example, the first code may include a unique identifier that identifies the closest local branch, and this branch may be suggested or selected as the customer's preferred local branch.

In certain embodiments, the customer device 104 may be used to take a picture of a form of identification that identifies the customer. Once the picture is scanned, the provider application may convert the information on the form of identification to digital data and the preliminary account information may be automatically populated into a preliminary account information field within the financial application, as will be discussed further with respect to FIGS. 6 and 7.

In some embodiments, once the preliminary account application information is received (e.g., by the provider institution computing system 106), the provider institution may perform a risk assessment. That is, the provider institution may analyze the account application response and determine whether additional processes are needed to verify the customer's identity. For example, the provider institution or entity may cross-reference information submitted by the customer in the account application response with other information available to the provider institution (e.g., information from a separate account with the provider institution, information provided by a consumer credit reporting agency, scraped information from a social media site(s), etc.) and perform a risk assessment regarding verifying the identity of the customer or other information. In some embodiments, the provider institution may proceed to open a new account for the customer after the risk assessment. For example, if the customer has an extensive credit history or already has an account with the provider institution, and the customer uploads two forms of identification, the bank may determine that no further processes need to be taken to verify the customer's identity. If the provider institution's risk assessment determines that the customer has complied with the provider institution's CIP, the process may skip to process 214. However, for example, if the customer does not have an extensive credit history and does not already have an account with the provider institution, the provider institution's CIP may require the provider institution to take further processes to verify the customer's identity, as will be discussed further herein.

In certain embodiments, part of the risk assessment may include providing a contact confirmation code to the customer device 104. It should be appreciated that the contact confirmation code may be different from the first code and the second code. For example, the contact confirmation code may be sent by the provider institution computing system 106 and/or the provider agent device 254. In some embodiments, the contact confirmation code may be used to confirm the phone number provided by the customer in the primary account application information. For example, a unique alphanumeric code may be sent as a text message to the phone number provided by the customer in the primary account application information. In some embodiments, the phone number may be associated with the customer device 104. The customer may then be prompted to enter the alphanumeric code into the webpage or application (e.g., the client application 132) as shown in FIG. 13 below.

In certain embodiments, process 206 may also include using the customer device 104 to take a selfie (i.e., a photograph of the customer using the customer device 104). For example, the customer may be prompted to take a photograph of the customer's face using the customer device 104. The selfie taken by the customer may then be included in the preliminary account application information. In certain embodiments, as an additional safety measure, facial recognition software may be used to confirm that the face captured in the selfie matches the face on the form(s) of identification uploaded on the customer device 104. The selfie may further be used to authenticate the identity of the customer. For example, the selfie may be used at process 308 as is discussed further herein.

Process 208 includes receiving a message to confer with an agent. For example, the message to confer with the agent may be received by the customer device 104. The message to confer with the agent may be sent to the customer device 104 by the provider institution computing system 106 and/or the provider agent device 254 in response to receiving the preliminary account application information from the customer device 104. The message (e.g., a push notification, an in-application message, an email, a text message, etc.) to confer with the agent may include instructions to provide identity information to a provider institution agent (e.g., banker). For example, the message to confer with the agent may include directing a customer to present a physical form, or multiple forms, of identification to an agent of the provider institution.

In some embodiments, the message to confer with the agent may be received by the customer via the customer device 104. For example, after a risk assessment is performed, and a determination is made that additional processes need to be taken to verify the customer's identity, a message notification may be displayed on the customer device 104. The message notification may include instructions to see an agent of the provider institution. The message to confer with the agent may then be displayed to the customer via the I/O device 136 of the customer device 104.

The message to confer with the agent may include instructing the customer to verify his or her ID with a banker or representative of the provider institution. The message may instruct the customer to verify his or her ID with the agent or representative in response to sending preliminary account application instructions. In an example embodiment, if the customer is at a local branch of the provider institution, the authentication instructions may include instructing the customer to see an agent at the local branch to verify the customer's ID. In another example embodiment, if the customer is not at a local branch or a mixer, the authentication instructions may include instructing the customer to go to the nearest local branch and verify the customer's ID at the local branch. The customer device 104 may utilize a GPS, or other location identification process, to determine the nearest branch. In this embodiment, a map may be launched within the application (e.g., the client application 132) or webpage and the message may include instructions for driving, biking, walking, and/or taking public transit to travel to the nearest local branch.

Process 210 includes capturing a second code. For example, the second code may be captured by the customer device 104. The second code may be captured by the customer device 104 in response to an agent verifying the identity of the customer. The second code is structured to confirm the identity of the customer based on a verification of identity information from the provider institution agent. Accordingly, the second code may also be referred to as an authentication code herein. The second code may be used to confirm that the customer has verified his or her identity with an agent of the provider institution in compliance with the provider institution's CIP and/or KYC program. By capturing the second code on the customer device 104, the agent may not have to use the provider agent device 254 to confirm that the customer has verified his or her identity with the agent.

In some embodiments, the second code may be a code, such as a bar code, a QR code, a PDF417, Code 39, Codabar, a token that is transmittable via a short-range wireless communication (e.g., a NFC token), etc. For example, the customer device 104 may be used to scan and capture the second code. In some embodiments, the second code may be a sequence of alphanumeric characters that may be captured by the customer device 104. For example, a customer may use the I/O device 136 of the customer device 104 to enter the alphanumeric characters into the customer device 104. Alternatively, the customer device 104 may be used to scan and capture the alphanumeric characters.

In some embodiments, the second code may be provided to a customer via a visual medium. For example, an agent of the provider institution may display the second code on paper, handout, digital display, etc. The customer may then use the I/O device 136 of the customer device 104 to enter the second code into the customer device 104 such that the customer device 104 may capture the second code. Further, the provider agent device 254 may display the second code to the customer. For example, the agent may use the provider application 232 to display the second code to the customer. The customer may then use the I/O device 136 of the customer device 104 to enter the second code into the customer device 104 such that the customer device 104 may capture the second code. Alternatively, the customer may use the customer device 104 to scan the second code being displayed on the provider agent device 254. The agent may provide the customer with a barcode printed on a piece of paper or another medium that can be scanned by the customer device 104.

In some embodiments, the second code may be provided to the customer via an audio medium. For example, the agent of the provider institution may verbally read the second code, or otherwise provide the second code, to the first customer. The customer may then use the I/O device 136 of the customer device 104 to enter the second code into the customer device 104 such that the customer device 104 may capture the second code.

In some embodiments, the second code may be provided to the first customer via a digital medium. For example, the agent of the provider institution may provide the second code to the customer device 104 in an email, text message, iMessage, etc. For example, the agent of the provider institution may email the second code to the customer in response to verifying the customer's identity. The second code may then be capture by the customer device 104. Further, the second code may be sent to the customer device 104 using NFC. For example, the customer device 104 may engage in an NFC tap with the provider agent device 254, which may send the second code from the provider agent device 254 (e.g., from the provider application 232) to the customer device 104 (e.g., to the client application 132) in response to agent verifying the customer's identity. Thus, the customer device 104 may capture the second code by NFC tap.

In some embodiments, the second code may include a biometric scan. For example, the customer device 104 may be capable of capturing a biometric scan. For example, the agent may provide a biometric scan on the customer device 104 in response to verifying the customer's identity. The biometric scan may then be a part the second code. Further, the biometric scan may be the second code. For example, at a mixer, the agent may individually provide a biometric scan on each customer device 104 in response to individually verifying each customer's identity.

In some embodiments, the second code may be generated before the customer's identity is verified by agent (i.e., a pre-determined second code). In some embodiments, the second code may be generated before the first code is captured by the customer device 104. For example, if an agent is attending a mixer, the agent may generate multiple second codes before the mixer event as is discussed further below with respect to FIGS. 3 and 14. By generating many pre-determined second codes, the agent does not need to generate a new second code after every customer's identity that has been verified, thereby accelerating the account application process.

In some embodiments, the second code may be generated after the first code is captured by the customer device 104 (i.e., a customer specific second code). For example, the account application authentication code may be an authentication code dynamically generated in real time via the provider agent device 254 (e.g., generated using the provider application 232). For example, the second code may be generated after the agent has verified the customer's identity, as will be discussed further below with respect to FIGS. 3 and 14.

In some embodiments, generating the second code may require the agent of the provider institution to securely log into the provider application 232 on the provider agent device 254. For example, the second code may be generated in response to the agent of the provider institution successfully logging into the provider agent device 254 using a secure login. Alternatively, or additionally, the provider agent device 254 may have a biometric reader (e.g., fingerprint scanner, eye scanner, facial recognition, voice recognition, etc.) that the agent of the provider institution may use to securely log into the provider agent device 254. For example, the second code may be generated in response to provider agent device 254 successfully taking a biometric reading of the agent of the provider institution.

In some embodiments, the second code includes unique identifiers. When generating the second code, the agent may enter in code generation parameters, which may be included as unique identifiers in the second code. For example, the location, date, and/or time of a mixer event may be embedded as unique identifiers within the second code. Further, the identity of an agent of the provider institution may be included as a unique identifier in the second code. Further, the location of a local branch of the provider institution may be included as a unique identifier in the second code. These unique identifiers may be embedded into the second code regardless of whether the second code is pre-determined or customer specific. In some embodiments, the customer may not be aware that this information is embedded within the second code. The unique identifiers in the second code may be similar to the unique identifiers in the first code.

In some embodiments, the second code may include customer specific unique identifiers. For example, if the second code is generated in response to the agent verifying the customer's identity, the agent may enter in customer specific information (i.e., code generation parameters) when generating the second code. For example, the agent may enter the name, initials, address, birthday, or any other identifying information that is representative of the customer that presents an ID for authentication as code generation parameters when generating the second code. This information may be entered into the provider agent device 254 when generating the second code. In this embodiment, the second code is specific to each customer. A carbon copy of this second code may be sent to the provider computing system after it is sent as well to the customer device 104. That way, the provider computing system may confirm the second code when it is received from the customer device 104.

In some embodiments, unique identifiers in the second code may be used for added security. For example, if the agent enters “Jane Doe” as the name of the customer and “May 28, 1993” as the birthday as code generations parameters, the authentication code may only be accepted by the provider institution for a customer named Jane Doe born on May 28, 1993, as indicated by the preliminary application information submitted at process 204. Further, the second code may include unique identifiers that may be compared to the unique identifiers of the first code. For example, if the first code received by customer device 104 includes a unique identifier that identifies the mixer that the customer is at (e.g., the location, time, date, agent at the mixer, etc.), then the second code may only be accepted by the provider institution computing system 106 if the unique identifiers in the second code align with the unique identifiers in first code.

In some embodiments, the second code may include restrictive parameters. For example, the authentication code may include a restrictive parameter that requires the authentication code to be provided within a certain time frame (e.g., within 24 hours of being created). Further, the second code may be embedded with a restrictive parameter (e.g., a time expiration period parameter) that requires the second code to be received within a predefined amount of time of the first code, and if the second code is not received with a predefined amount of time of the first code, the second code is not validated.

The authentication code may include a restriction requirement that the authentication code may only be used in conjunction with a specific event. For example, when account application instructions are received at process 202, the account application instructions may include instructing the customers at the event to enter in the location and/or event that they are at when beginning the account opening process 200. Further, the customer device 104 may use a GPS or other location identification method to determine the location of the customer device. This location may then be compared to a restrictive parameter that restricts what location the second code may be used at. Additionally, if the customer captures the first code by scanning a barcode, the location and/or specific mixer may be built into the barcode (e.g., as unique identifiers), and therefore automatically recognized by the customer device 104 when the barcode is scanned. In this example embodiment, the second code may include restrictive parameters that only allow the authentication codes to be successfully submitted by customers that scanned the barcode at the mixer, are at the mixer (e.g., the GPS of the customer device 104 indicates that the customer device 104 is within a specified geographic perimeter), and/or the customer indicated that they are at a specific mixer when the customer submitted the preliminary account application information. Further, the second code may include a restrictive parameter that the second code may only be used once, and any subsequent attempt to use the second code may be unsuccessful. The second code may include the above listed restrictive parameters and any other restrictive parameter.

Process 212 includes sending the second code. For example, the account application authentication code may be sent by the customer device 104 to the provider institution computing system 106. The second code may then be verified by the provider institution computing system 106, which may eliminate the need for the agent to verify the customer's account application on the provider agent device 254.

In some embodiments, the second code may be automatically sent by the customer device 104. For example, once the customer has entered the second code into the customer device 104, the second code may be automatically sent to the provider institution computing system 106. Further, if the customer uses the customer device 104 to scan a second code (e.g., a barcode), the application (e.g., the client application 132) or webpage may automatically send the second code in response to scanning the second code. Similarly, if the second code includes the agent providing a biometric scan on the customer device 104 as a second code, the digitized biometric scan may be automatically sent by the customer device 104 once the biometric scan is complete. In other embodiments, the customer may choose to send the second code using the customer device 104.

Once the second code is received by the provider institution computing system 106, the second code is verified. For example, the second code may be verified by confirming that the second code was generated by the provider institution computing system 106 or the provider agent device 254 by comparing the second code received to a list of second codes that have been generated. Further, the second code may be verified by comparing and unique identifiers in the second code to the preliminary account application information, the unique identifiers in the first code, and any other parameters that the unique identifiers may be compared to. Furthermore, the second code may be verified by checking the restrictive parameters built into the second code. An account may be opened in response to verifying the second code.

Process 214 includes accessing the account. For example, the account may be accessed by the customer device 104. The provider institution computing system 106 may receive the second code from the customer device 104 and complete the account opening in response to verifying the account application authentication code. In certain embodiments, an account opening notification may be displayed on the customer device 104 that indicates that the customer has successfully opened an account with the provider institution. In certain embodiments, completing the account opening enables the customer to access a newly opened account with the provider institution using the customer device 104 and/or any other device that may be connected to the network 108. In some embodiments, the account information may be stored in the account database 146 of the provider institution computing system 106. The customer device 104 may be configured to access and/or modify account information stored in the account database 146 of the provider institution computing system 106.

Providing customers with the second code may expedite the account opening process. For example, if the agent of the provider institution provides the customer with a second code, the account may be opened immediately when the pre-determined account application authentication code is received and verified by the provider institution computing system 106. Therefore, the agent of the provider institution does not need to verify and authorized the application on the provider agent device 254 or any other device connected to the network 108. This may reduce the turnaround time required to open a new account, thereby providing customers access to a new account sooner.

Referring now to FIG. 3, an account opening process 300 is shown according to an example embodiment. In some embodiments, the account opening process 300 may be performed by the provider institution computing system 106 and/or the provider agent device 254. It should be appreciated the account opening process 300 may be performed in any order and that certain processes may be omitted.

Process 302 includes generating a first code. Generating the first code may be done by the provider institution computing system 106 and/or the provider agent device 254. In some embodiments, the first code may be generated using the provider application 232. In further embodiments, the first code may be generated by a third party and provided to the provider institution for distribution. Process 302 may be similar to process 202. For example, the first code generated at process 302 may be the first code captured at process 202.

Process 304 includes providing the first code. In some embodiments, the first code may be provided to a customer device 104 via the provider institution computing system 106 and/or the provider agent device 254. Process 304 may be similar to process 202 and process 204. For example, the first code may be provided to the customer and/or customer device 104 in a similar manner discussed in process 202 and process 204. Further, process 304 may include providing account application instructions to a customer and/or customer device 104 in a similar manner as described in process 204.

Process 306 includes receiving preliminary account information (i.e., customer information). In some embodiments, the preliminary account information may be received by the provider institution computing system 106 and/or the provider agent device 254. For example, preliminary account information may be sent by a customer device 104 and received by the provider institution computing system 106 and/or the provider agent device 254. Process 306 may be similar to process 206. For example, the preliminary account application information sent at process 206 may be received at process 306.

Process 308 includes authenticating the preliminary account information. For example, the preliminary account information that is received by the provider institution computing system 106 and/or the provider agent device 254 at process 306 may be authenticated by the provider institution computing system 106 and/or the provider agent device 254. As discussed above, authenticating the preliminary account information may include performing a risk assessment. That is, the provider institution or entity may analyze the preliminary account information received at process 306 and determine whether additional processes are needed to verify the customer's identity. For example, the provider institution or entity may cross-reference information submitted by the customer in the account application response with other information available to the provider institution (e.g., information from a separate account with the provider institution, information provided by a consumer credit reporting agency, etc.) and perform a risk assessment regarding verifying the identity of the customer.

In certain embodiments, the preliminary account information includes the customer's preferred local branch. In this embodiment, the preliminary account information may be authenticated according to the local branch's rules (e.g., in accordance with the local branches CIP and/or KYC programs).

Decision 310 includes determining whether or not the digital authentication is complete. For example, decision 310 may be performed by the provider institution computing system 106 and/or the provider agent device 254. As discussed above, in some embodiments, the provider institution computing system 106 may proceed to open a new account for the customer after the risk assessment performed as a part of authenticating the preliminary account information. For example, the provider institution computing system 106 may determine that the requirements of the local branch's CIP and/or KYC program have been satisfied. For example, if the customer has an extensive credit history or already has an account with the provider institution, and the customer uploads two forms of identification, the bank may determine that no further process need to be taken to verify the customer's identity. However, if the customer does not have an extensive credit history and does not already have an account with the provider institution, the provider institution's CIP and/or KYC program may require the provider institution to take further processes to verify the customer's identity, as will be discussed further herein. If the digital authentication is completed, the account opening process 300 may proceed to process 312. If the digital authentication is not complete, the account opening process may proceed to process 314.

Process 312 includes opening an account. For example, the provider institution computing system 106 and/or the provider agent device 254 may open an account in the name of the customer that submitted the preliminary account information. As discussed above, the account may be accessed by the customer device 104. In certain embodiments, process 312 further includes sending a notification to the customer device 104. For example, a notification may be sent by the provider institution computing system 106 and/or the provider agent device 254 to a customer device 104. The notification may indicate that a new account has been successfully opened and that the account may be accessed immediately by the customer. For example, the customer may access the account on a customer device 104.

Process 314 includes sending a message to confer with an agent. For example, a message or notification (i.e., a stop message, stop notification, etc.) may be sent by the provider institution computing system 106 and/or the provider agent device 254 to the customer device 104. As discussed above, the stop notification may include instructions to verify a customer's physical form of identification with an agent. For example, if the customer is at a mixer, the stop notification may instruct the customer to see an agent that is at the mixer to verify the customer's identification. The customer may then verify his or her identity with the agent according to the provider institution's CIP and/or KYC program. It should be appreciated that process 314 may share any or all characteristics with account opening process 200. Specifically, process 314 may include any of all processes described in process 208 described above.

Process 316 includes providing a second code. For example, a second code may be provided to the customer device 104. As discussed above, in some embodiments, the second code may be provided to the customer device 104 by the provider institution computing system 106 and/or the provider agent device 254. Further, the second code may be provided by the agent to the customer in response to the agent verifying the agent's identity. The second code may share some or all characteristics of the second code described with respect to the account opening process 200 above. Further, the second code may be sent (i.e., provided) to the customer any way that is described with respect to the account opening process 200 above. As discussed herein, the second code may be pre-determined or customer specific. Further, the second code may be generated to include unique identifies. Furthermore, the second code may be generated to include restrictive parameters. In some embodiments, the second code may be generated using the provider application 232. In some embodiments, the second code may be generated by a third party and distributed by the provider institution.

Process 318 involves receiving the second code. For example, the second code may be received by the provider institution computing system 106 and/or the provider agent device 254. Process 318 may be similar to process 212. For example, the second code sent at process 212 may be received by at process 318.

Process 320 involves opening an account. For example, the provider institution computing system 106 and/or the provider agent device 254 may open an account after the second code has been verified in the name of the customer that submitted the preliminary account information. Process 320 may be similar to process 312.

Referring now to FIGS. 4-13, multi-feature graphical user interfaces (“GUIs”) are shown according to an example embodiment. For example, the GUIs may be displayed on the customer device 104 during the account opening process 200 and/or the account opening process 300. Thus, the GUIs may enable any of the functionality that is described with respect to process 200 and/or process 300. The GUIs may be displayed in the client application 132 (e.g., a browser and/or an application). The GUIs enable the customer to receive account application instructions, enter preliminary account information, receive authentication instructions, enter an account application authentication code, access an account, and any other processes that are described herein.

Referring now to FIG. 4, a GUI is shown according to an example embodiment. In some example embodiments, this GUI may be displayed on a customer device 104 in response to receiving account application instruction as described with respect to process 202 and/or process 304. For example, if a first code is scanned, a browser may be opened, and the GUI of FIG. 4 may be displayed on the customer device 104. Further, if a URL is entered into the customer device 104, a browser may be opened, and the GUI of FIG. 4 may be displayed on the customer device 104. Furthermore, if a customer device 104 downloads an application (e.g., the client application 132), the GUI of FIG. 4 may be displayed on the customer device 104 when the application is opened.

The GUI of FIG. 4 includes an account application instructions area 402 according to an example embodiment. For example, as shown, the account application instructions area 402 may include a description of the items (e.g., forms of identification) a customer may need to open an account. The required items may vary based on the type of account that the customer wishes to open and any local branch rules that may apply to the customer. Any unique identifiers that are included in the first code (see process 302 above) may be used to customize the account application instructions. For example, if the first code includes a unique identifier that identifies the local branch, the account application instructions area 402 may be updated based on that banks CIP and/or KYC program.

The GUI of FIG. 4 also includes a current customer inquiry area 404. The current customer inquiry area 404 allows the customer to use the customer device 104 to select whether or not the customer already has an account with the provider institution. As discussed above, if the customer already has an account with the provider institution, there may be less processes needed to verify the customer's identity in accordance with the provider institution's CIP and/or KYC programs.

The GUI of FIG. 4 also includes a continue application function 406. If a customer selects the continue application function 406, the customer may continue an application that he or she previously started. For example, a customer may start an application and the partially completed application may be stored on the provider institution computing system 106. The customer may then use the continue application function 406 to access the previously started application and complete the account opening process.

The GUI shown in FIG. 4 also includes a help icon 501. The help icon 501 may be selected to provide more information about the information that is being requested. For example, if the help icon 501 is selected, more information may be presented about what the customer may need to start an account (e.g., a driver's license, a state ID, a social security number, and/or an ITIN number).

Referring now to FIG. 5, a GUI is shown according to an example embodiment. In some embodiments, the GUI in FIG. 5 may be displayed on the customer device 104. For example, if the customer uses the GUI to indicate that he or she does not currently have an account with the provider institution, then the GUI of FIG. 5 may be presented. In some example embodiments, the GUI includes a preliminary account information area 408. For example, a customer may enter preliminary account information (e.g., first name, middle initial, last name, id type, id number, expiration date, date of birth, street address, city, state, zip code, etc.) into the preliminary account information area 408 using the customer device 104. In some embodiments, some of the preliminary account information may be automatically populated. For example, if the customer uses the customer device 104 to scan a first code to receive account application information (e.g., process 202), the first code may include unique identifiers. The unique identifiers may be used to automatically populate certain preliminary account application information. For example, if the first code is presented at a mixer, the city, state, and zip code of the mixer may be included as unique identifiers in the first code and may be automatically populated into preliminary account information area 408.

The GUI displayed in FIG. 5 also includes an identification upload option 410. If a customer selects the identification upload option 410, the customer may be prompted to use his or her customer device 104 to upload a picture of physical identification that identifies the customer. For example, if the customer selects the identification upload option 410, the GUI of FIG. 6 may be displayed on the customer device 104.

The GUI displayed in FIG. 5 also includes a first help icon 503 and a second help icon 505. The help icons 503, 505 may be selected to provide more information about the information that is being requested. For example, if the first help icon 503 is selected, more information may be presented about the accepted types of identification. For example, a pop-up may be displayed that includes a message that indicates the form of identification must include a photo of the customer or the signature of the customer. The pop-up may also include a list of acceptable forms of identification (e.g., a consular card, a credit card, a debit card, a driver's license, employment authentication card, employer ID, municipal ID, passport, permanent resident card, state ID, student ID, etc.). Further, if the second help icon 505 is selected, more information may be displayed about the street address that is requested (e.g., billing address, current residence, business address, etc.).

Referring now to FIG. 6, a GUI is shown according to an example embodiment. For example, the GUI of FIG. 6 may be displayed on the customer device 104 in response to a customer selecting the identification upload option 410 as described above. According to an example embodiment, the GUI of FIG. 6 has an identification information section 412. In the identification information section 412, the customer may select the issuer (e.g., state, country, university, military branch, etc.) of the customer's physical form of identification. Further, the identification information section 412 may have a front of identification option and a back of identification option. In some example embodiments, when a customer selects the front of identification option, the customer device 104 may launch a camera in the customer device and instruct the customer to take a picture of the front side of the customer's physical form of identification. When a customer selects the back of identification option, the customer device 104 may launch a camera (e.g., within the client application 132) in the customer device and instruct the customer to take a picture of the back of the customer's physical form of identification. The images of the physical form of identification may then be scanned, and certain information from the physical form of identification may be digitized and the preliminary account information area 408 may be partially or completely automatically populated based on the information captured from the customer's form of identification. For example, the preliminary account information area 408 may be automatically populated on a customer device 104 as shown in FIG. 7.

The GUI displayed in FIG. 6 also includes a first help icon 507 and a second help icon 509. The help icons 507, 509 may be selected to provide more information about the information that is being requested. For example, if the first help icon 507 is selected, more information may be presented about what side of the ID constitutes the front side of the ID. Further, if the second help icon 509 is selected, more information may be presented about what side of the ID constitutes the back side of the ID.

Referring now to FIG. 8, a GUI is shown according to an example embodiment. For example, the GUI of FIG. 8 may be displayed on the customer device 104 in response to a customer using a customer device 104 to send preliminary account information to the provider institution computing system 106 (e.g., process 204). The GUI may include a funding selection area 414. For example, the customer may be given the option to fund the new account with a debit or credit card, the customer may transfer funds from an account at another bank, or the customer may fund his or her new account using online banking.

Referring now to FIG. 9, a GUI is shown according to an example embodiment. For example, the GUI may be displayed on a customer device 104. The GUI of FIG. 9 may be presented on the customer device 104 as a part authenticating the customer's preliminary account information (e.g., process 308). The GUI of FIG. 9 may instruct the customer to verify his or her identity by confirming a digital CIP authentication code. For example, the customer may enter his or her phone number into a contact field 416. The contact field 416 may also be automatically populated using the phone number provided by the customer when entering the preliminary account information. The GUI of FIG. 9 may also have a contact method field 418 that the customer may use to select the delivery method of the contact confirmation code (e.g., voicemail, text message, email, etc.). Once the customer has completed the contact field 416 and the contact method field 418, the customer may receive a digital CIP authentication code. For example, the customer may receive the contact confirmation code via text message on the customer device 104.

Referring now to FIG. 10, a GUI is shown according to an example embodiment. For example, the GUI may be displayed on a customer device 104. The GUI of FIG. 10 may have a preliminary account information review area 420. Some or all of the customer's preliminary account information that has either been entered by the customer or automatically populated may be displayed on the customer device 104 in the preliminary account information review area 420. This gives the customer an opportunity to review the preliminary account information and check it for accuracy.

Referring now to FIG. 11, a GUI is shown according to an example embodiment. For example, the GUI may be displayed on a customer device 104. The GUI may have a second ID selection area 422. For example, the second ID selection area 422 may include instructions for the customer to select the type of identification the customer would like to use as a second form of identification. The GUI shown in FIG. 11 also includes a first help icon 511 and a second help icon 513. The help icons 511, 513 may be selected to provide more information about the information that is being requested. For example, if the first help icon 511 is selected, more information may be presented about the second form of ID that is required. Further, if the second help icon 513 is selected, more information may be presented about the accepted types of identification. For example, a pop-up may be displayed that includes a message that indicates the form of identification must include a photo of the customer or the signature of the customer. The pop-up may also include a list of acceptable forms of identification (e.g., a consular card, a credit card, a debit card, a driver's license, employment authentication card, employer ID, municipal ID, passport, permanent resident card, state ID, student ID, etc.).

Referring now to FIG. 12, a GUI is shown according to an example embodiment. For example, the GUI may be displayed on a customer device 104. The GUI may have a second ID information area 415. In certain embodiments, the customer may use the customer device 104 to enter in details of a second form of identification. Alternatively, the customer device 104 may be used to scan the second form of identification and the information may be automatically entered into the second ID information area 415. The second ID information area 415 may vary based on the type of identification being used as a second identification form. For example, if the second identification form is a debit card, the second ID information area 415 may include information fields for the issuing financial institution, the card number or part of the card number (e.g., the last four digits), the issue date, and the expiration date. Once the second ID information is entered into the second ID information area 415, the second ID information may be accessed by the provider institution. In some embodiments, the provider institution may perform a risk assessment to determine if the customer and the customer's application have satisfied the provider institution's CIP and/or KYC program (e.g., decision 310). If the customer and the customer's application have satisfied the provider institution's CIP and/or KYC program, the customer may be presented the terms and conditions of having an account with the provider institution, such as shown in FIG. 14. If the customer and the customer's application has not satisfied the provider institution's CIP and/or KYC program, then a notification may be displayed on the customer device 104 as shown in FIG. 13.

Referring now to FIG. 13, a GUI is shown according to an example embodiment. For example, the GUI may be displayed on the customer device 104. The GUI may have an ID confirmation notification area 417. For example, the ID confirmation notification area 417 may present a message to the customer instructing the customer to show the customer's ID(s) to the agent of the provider institution. The ID confirmation notification area 417 may instruct the customer to present the two forms of ID that had previously been entered into the user device 104. The GUI may also include a customer information area 419. For example, the ID information (e.g., information from the first form of ID and/or the second form of ID) entered into the user device 104 may be displayed in the customer information area 419. The information displayed in the customer information area 419 may be used by the customer to ensure that the customer presents the correct form(s) of identification to the agent of the provider institution. Further, the information displayed in the customer information area 419 may be viewed by the agent of the provider institution when the agent is confirming the customer's identity. For example, the customer may show the agent the customer device 104 along with the customer's form(s) of identification. In certain embodiments, the customer information area 419 may be scaled such that the entire customer information area 419 is viewable on a small mobile screen (e.g., a cell phone screen) on the customer device 104. In this example embodiment, the entire customer information area 419 may be viewed by the agent of the provider institution without scrolling on the customer device 104. Further, the GUI has a second code area 421. For example, the customer may enter in the second code into the second code area 421 such that the second code may be captured by the customer device 104. Alternatively, the second code may be scanned or otherwise received by the customer device 104 such that the second code is automatically populated into the second code area 421. Once the second code is entered into the second code area 421, the second code may be accessed by the provider institution.

The GUI shown in FIG. 13 also includes a first help icon 519, a second help icon 521, and a third help icon 523. The help icons 519, 521, 523 may be selected to provide more information about the information that is being requested. For example, if the first help icon 519 is selected, more information may be presented about the primary ID may be displayed on the customer device 104. For example, a pop-up may be displayed on the screen of the customer device 104 that indicates that the Primary ID is the ID that the customer entered in the application. Further, if the second help icon 521 is selected, more information may be presented about the secondary ID may be displayed on the customer device 104. For example, a pop-up may be displayed on the screen of the customer device 104 that indicates that the second ID is the ID that was entered later in the application. Further, if the third help icon 523 is selected, more information may be displayed about the code (e.g., the second code) that is being required. For example, a pop-up may be displayed on the screen that informs the customer that the code indicates to the provider institution that the agent has verified the customer's form(s) of identification, which helps the provider institution process the customer's application.

Referring now to FIG. 14, a GUI is shown according to an example embodiment. Fr example, the GUI may be displayed on a customer device 104. The GUI shown in FIG. 14 includes a terms and conditions area 424 that may display some or all of the terms and conditions of the provider institution. Further, there may be a consent box, where the customer may consent and opt into the terms and conditions. Once the customer consents to the terms and conditions, a new account may be opened for the customer (e.g., process 312). For example, the GUI shown in FIG. 15 includes an account status area 426 where the status of the customer's application may be displayed. For example, the account status area 426 may notify the customer that the account has been opened, at which point the customer may access his or her account.

Referring back to the risk assessment that may be performed after the customer enters the digital CIP authentication code, if it is determined that the customer has not satisfied the provider institution's CIP and/or KYC program, a notification may be displayed on the customer device 104 indicating that the customer must present a physical form, or multiple forms, of identification to an agent of the provider institution (e.g., process 314). The customer may then present a form of identification and complete any other authentication instructions that are presented to the customer (e.g., process 208). In response to verifying the customer's identity with the agent, the agent may provide the customer with a second code (e.g., process 316). The second code may then be received by the customer device 104 (e.g., process 210). The customer device 104 may then send the second code (e.g., process 212) to the provider institution computing system 106 and/or provider agent device 254 (e.g., process 318). Once the provider institution has verified the second code, the terms and conditions may be presented to the customer, such as described above with respect to FIG. 14. Once the customer consents to the terms and conditions, the provider institution computing system 106 may open an account (e.g., process 320) and a notification may be sent to the customer that the account has been opened, as described above with respect to FIG. 15. The customer may then access his or her account (e.g., process 214).

Referring now to FIG. 16, a GUI is shown according to an example embodiment. For example, the GUI may be displayed on a provider agent device 254. For example, the GUI may be displayed on a webpage or within an application. In some embodiments, the GUI of FIG. 16 may be displayed within the provider application 232. The GUI shown in FIG. 16 may be used, for example, to create a second code (e.g., the second code used at process 318, the account application authentication code used at process 210). In some embodiments, the GUI includes a location field 502. An agent of the provider institution may use the provider agent device 254 to enter a location into the location field 502. The location may be of a local branch, mixer, an advertisement, etc. The location entered into the location field 502 may then be included as a unique identifier when the second code is generated. The GUI may also include and agent identification area 504. An agent of the provider institution may use the provider agent device 254 to enter information identifying into the agent identification area 504. For example, the agent identification area may be updated to include the agent's name, agent's identification number, and/or any other information that may identify the agent. The information entered into the agent identification area 504 may be included as a unique identifier when the second code is generated. The GUI may also include a quantity field 506. An agent of the provider institution may use the provider agent device 254 to enter a number of desired codes that the agent would like to create. For example, the agent may know how many or be able to estimate how many customers may attend a mixer. It should be appreciated that the GUI may include other fields that may be filled with information that may be included as a unique identifier in the second code.

In certain embodiments, such as when the agent is at an off-site (i.e., not at a local branch) mixer, the agent may use the GUI shown in FIG. 16 to generate multiple second codes (e.g., predetermined account application authentication codes) before the mixer starts, thereby accelerating the account opening process. However, an agent may also use the provider agent device 254 to generate second codes in real time while at the off-site mixer. When the agent is at a local branch and helping customers create new accounts, the agent may use the GUI of FIG. 16 to generate a second code in real time for a customer upon verifying a customer's identity in accordance with the provider institution's CIP and/or KYC program.

Referring now to FIG. 17, a flow diagram of another account opening process 1700 is shown, according to an example embodiment. The account opening process 1700 may be utilized by a provider institution to facilitate opening a customer account. For example, the account opening process 1700 may be utilized by a provider agent to assist a customer open an account while the two parties meet (e.g., in person, virtually, etc.). In some embodiments, the account opening process 300 may be performed by the customer device 104, the provider institution computing system 106 and/or the provider agent device 254. It should be appreciated that the account opening process 1700 may be performed in any order and that certain processes may be omitted.

The account opening process 1700 may involve two or more parties, such as a customer (e.g., a user) and a provider agent (e.g., an agent). As discussed further, the customer and the provider agent may interact with one another for some or all of the account opening process 1700. According to various embodiments, the customer operates a customer device 104 and the provider agent operates the provider agent device 254. The customer device 104 and the provider agent device 254 may not be in direct communication with one another. Further, the customer device 104 and/or the provider agent device 254 may communicate with the provider institution computing system 106. According to various embodiments, the account opening process 1800 is performed entirely by the provider agent device 254 and the provider institution computing system 106.

Process 1710 includes receiving preliminary account information. For example, the provider agent device 254 may receive preliminary account information (e.g., account information, customer information, user information, etc.) via the input/output device 236. For example, the provider agent may input preliminary account information into the provider agent device 254. Process 1710 may involve the customer communicating (e.g., verbally, via a written document, or any combination thereof) the preliminary account information to the provider agent such that the provider agent may input the preliminary account information into the provider agent device 254.

The preliminary account information may include information about the applicant (i.e., the customer) that is needed to open an account with the provider institution. Some or all of the preliminary information may also be required by the provider institution's CIP and/or KYC program. For example, the preliminary information may include the customer's first name, middle name, last name, customer's email address, customer's phone number, customer's date of birth, address, city, state, and zip code. The preliminary account information may also include information about a form of identification the customer may wish to use to verify the customer's identity. For example, the preliminary account information may include the type of identification (e.g., passport, driver's license, birth certificate, student ID, credit card, debit card, insurance card, etc.) and the identification number (e.g., social security number, driver's license number, passport number, etc.).

According to various embodiments, some of the preliminary account information may be submitted via a pin pad that is included in or coupled to the provider agent device 254 (e.g., a point-of-sale type device with a PIN pad). For example, the customer may be prompted to enter a Social Security Number into the pin pad such that the social security number does not need to be verbally communicated to the banker. The Social Security Number may be included in the preliminary account information.

According to various embodiments, some or all the preliminary account information may be received from the provider institution computing system 106. For example, the customer may have previously opened or applied for an account with the provider institution. The provider institution computing system 106 may retrieve some or all the previously received preliminary account information (e.g., from the memory 144) and provide the preliminary account information to the provider agent device 254.

In various embodiments, the preliminary account information includes the customer's preferred local branch. In this embodiment, the preliminary account information may be authenticated according to the local branch's rules (e.g., in accordance with the local branches CIP and/or KYC programs).

In various embodiments, the preliminary account information includes one or more offer codes or promotional codes. An offer code may cause a bonus to be activated in response to opening the new account. For example, the offer code may activate a monetary bonus or a special interest rate. For example, the provider agent may determine one or more offer codes and select the one or more offer codes. Additionally, or alternatively, the customer may present the offer code to the provider agent (e.g., via a handout, shown on the customer device 104, etc.). The one or more offer codes are included in the preliminary account information and can subsequently be accepted or denied by the customer. The one or more offer codes may be specific to a provider agent and/or a local branch location. For example, adding an offer code to the preliminary account information may cause certain preliminary account information to be automatically populated.

According to various embodiments, process 1710 may include asking the customer a series of questions to determine which products and/or services are suited or most suited for the customer's needs. For example, a series of questions may be displayed on the provider agent device 254 and the banker may communicate those questions to the customer. Alternatively, a screen of the provider agent device 254 or a screen coupled to the provider agent device 254 may be visible to the customer (e.g., swiveled towards) such that the customer can directly answer the questions. Additionally, or alternatively, the series of questions may be displayed on the customer device 104 such that the customer is able to answer the series of questions directly on the customer device 104.

According to various embodiments, the provider agent device 254 enters a protected screen share mode before the screen is shown to the customer. For example, the provider agent may select the protected screen share mode and then swivel the screen towards the customer so that the customer can review and enter answers to the series of questions. In the protected screen share mode, sensitive information may be hidden and the provider agent device 254 may be prevented from closing or minimizing the series of questions such that other information is not displayed to the customer. In order to exit the protected screen share mode, a password or other credential may need to be entered. For example, the provider agent may use his or her device password, which is not known by the customer. Additionally, or alternatively, the provider agent may need to provide a biometric scan to turn off the protected screen share mode. The protected screen share mode transforms the provider agent device 254 into a relatively secure sensitive receiving information device that prevents, at least partly, the user (i.e., the customer) from accessing information that may be available on the device 254. This may enable the provider agent to substantially provide the device 254 to the customer without fear of accessing unwanted information. For example, a second credential may be required by the provider agent to exit the protected secure share. In some embodiment, the second credential may be different from the first credential that enables access to the protected screen share mode.

After entering the preliminary account information, a customer profile (e.g., a slim profile) may be created. It is referred to as a “slim profile” because the customer profile contains only the basic information and not other information that may be verified by third-parties or other entities. The customer profile may include some or all of the preliminary account information, one or more unique identifiers, and/or any other information discussed herein. The customer profile may be saved and retrieved by one or more of the devices described herein.

Process 1715 includes authenticating the preliminary account information. For example, the preliminary account information that is received by the provider institution computing system 106 and/or the provider agent device 254 at process 306 may be authenticated by the provider institution computing system 106 and/or the provider agent device 254. As discussed above, authenticating the preliminary account information may include performing a risk assessment. Thus, the provider institution or entity may analyze the preliminary account information received at process 306 and determine whether additional processes are needed to verify the customer's identity. For example, the provider institution or entity may cross-reference information submitted by the customer in the account application response with other information available to the provider institution (e.g., information from a separate account with the provider institution, information provided by a consumer credit reporting agency, etc.) and perform a risk assessment regarding verifying the identity of the customer (e.g., as described further herein).

As a part of the risk assessment, the provider institution computing system 106 may determine that the requirements of the local branch's CIP and/or KYC program have been satisfied. For example, if the customer is a new customer, the customer may present multiple and, particular two, forms of identification to the provider agent. The provider agent may determine that no further process need to be taken to verify the customer's identity. However, in other examples, the provider institution's CIP and/or KYC program may require the provider institution to take further processes to verify the customer's identity, as discussed further herein.

According to various embodiments, process 1715 includes manually checking one or more forms of a customer's identification (e.g., passport, driver's license, birth certificate, Social Security card, student ID, credit card, debit card, insurance card, etc.). For example, the customer may show the provider agent of the provider institution the customer's form(s) of identification to verify the customer's identity. The provider agent may cross-reference the information in the customers form(s) of identification with the preliminary account information received by the provider agent device 254 to verify the customer's identity. In response to the identification being authenticated and the customer's identity being verified, the employee may cause an authentication code to be included with the preliminary account information. The authentication code may pre-authorize an account to be opened in the customer's name, as discussed further herein. For example, the customer may then access his or her account once the authentication code is received and verified by the provider institution computing system 106.

According to various embodiments, authenticating an existing customer may include requiring the customer to swipe an existing transaction card (e.g., a debit card or credit card). Authenticating the existing customer may include requiring the entering a value, such as numerical value (e.g., a PIN for a debit card), an alpha value, and/or alphanumerical value or code. Authenticating the existing customer may include requiring the customer to answer one or more security questions (e.g., that were answered previously by the customer when setting up an account). Authenticating the existing customer may include requiring the customer to present/provide a token (e.g., stored on the customer device 104). For example, the token may be communicated to the provider agent device 254 via a short range wireless communication (e.g., an NFC tap). The device token for the customer device may be stored by the provider computing system and checked via the tap to confirm whether the transmitted/provided token aligns with the stored token for verification. The provider agent may further request a form of ID be presented along with the token to confirm the identity of the token.

Process 1720 includes generating a first code. For example, the first code may be generated by the provider agent device 254 in response to receiving the preliminary account information and/or authenticating the preliminary account information. Process 1720 may further include displaying the first code on the provider agent device 254 for capture by the customer device 104. For example, after generating the first code, the first code may be displayed on a screen (e.g., the input/output device 236) such that the first code may be captured by user customer device 104. By providing a code to the customer device 104, the preliminary account information may be provided to the customer device 104 without the customer device being in direct communication with the provider agent device 254, which may improve security and efficiency of the process. According to various embodiments, the provider agent device 254 is placed in a protected screen share mode before the screen (e.g., displaying the first code) is shown to the customer.

When the customer device 104 captures or scans the first code, a browser or a corresponding application (e.g., the client application 132) may be launched on the customer device 104. The first code may be embedded with computer code to cause a launching or activation of the client application 132, which may be a specific application (e.g., a mobile banking application) or a web browser application. Alternatively, the first code may be a URL that, when captured on the customer device 104 (e.g., entered using the input/output device 136, captured via a camera of the customer device 104, etc.) launches a browser. The browser may display a website with additional account application instructions. Further, the browser may direct a customer to download an application (e.g., the client application 132 when it is embodied as a specific application and not the web browser) on the customer device 104.

In some embodiments, the first code may be provided to the customer via an audio medium. For example, the agent of the provider institution may verbally read the first code, or otherwise provide the first code, to the first customer.

In some other embodiments, the first code may be provided to the customer device 104 via a digital medium. For example, the agent of the provider institution may provide the first code to the customer device 104 in an email, text message, iMessage, etc. For example, the agent of the provider institution may email the first code to the customer's email address. In this case and rather than being a scannable, the first code may be configured as a URL. The URL may be unique (i.e., include unique identifiers) for the specific to the customer, the provider agent, and/or a local branch, as will be discussed further herein. When the customer selects the URL on the customer device 104, the client application 132 (e.g., a mobile banking application, a browser, etc.) may be launched on the customer device 104. For example, the browser may display a website with account application instructions. Further, the browser may direct a customer to download an application on the customer device 104, such as the client application 132.

Further, the first code may be captured by the customer device 104 via a short range wireless communication, such as a Bluetooth communication or, preferably, a NFC transmission. For example, the first code may be stored on the provider agent device 254 and sent to the customer device 104 via NFC tap, such that the customer device 104 captures the first code. The NFC taps adds security to the process because of the requirement that the provider agent device and customer device 104 be positioned within a NFC tap distance from each other, which is usually less than five centimeters.

The first code may be embedded with data (e.g., unique identifiers). For example, the first code may include one or more unique identifiers that include some or all of the preliminary account information. In this sense, the first code may be specific to the customer. The unique identifier may include one or more codes (e.g., alphanumeric sequences) that are generated (e.g., by the provider agent device 254, the provider institution computer system 103, and/or the user device 104). Each code may be specific to a specific characteristic of the user account (e.g., branch location, provider agent identity, customer account number, etc.). According to various embodiments, the first code includes preliminary account information such that capturing the first code on the customer device 104 may launch a browser or an application in response to capturing the first code thereby causing a display of a graphical user interface comprising one or more fillable fields with at least one of the one or more fillable fields populated with preliminary account information from the captured first code. Some or all the account information may be specific to a user account and therefore may accelerate the account opening process.

According to various embodiments, the browser or application may allow the user to input additional account information. For example, the browser or application may include fields that allow a user to enter or populate with sensitive information regarding the customer (e.g., account passwords, identification numbers such as social security numbers, account numbers, etc.). Further, the browser or application may include fields that allow the customer to customize a card (e.g., a credit card, a debit card, etc. to include, for example, specific card art). The browser or application may include a field to enter a W9 certification. Furthermore, the browser or application may include a field that allows the customer to link another account to the user account (e.g., for funding of the new account).

Further, the first code may include one or more unique identifiers that includes the authentication code. As discussed herein, the authentication code may pre-authorize an account to be opened in the customer's name. Thus, when submitting a customer confirmation, as discussed further herein, the customer confirmation may include the authentication code such that the customer may access the account in real time without the need for further authentication to be done after submitting the customer confirmation.

Furthermore, the first code may cause a customer confirmation request (e.g., a user confirmation request) to be launched on the customer device 104 (e.g., within the browser or the application). The customer confirmation request may be a graphical user interface that includes a terms and conditions area that may display some or all of the terms and conditions of the provider institution. Further, there may be a consent area that the customer may use to consent and opt into the terms and conditions.

Additionally, the first code may include a unique identifier including a security code. The security code may be specific to the customer account such that the security code cannot be used in conjunction with any other customers and/or customer accounts. The security code may be an alphanumeric code that is generated in response to the preliminary account information being received. The security code may be provided to the provider institution computing system 106 by the provider agent device 254, captured by the user device 104 (e.g., when the first code is captured) and subsequently provided to the provider institution computing system 106 by the user device 104. For example, when submitting the customer confirmation, the customer device 104 may further provide the security code. Before opening the customer account, the provider institution computing system 106 may determine the security code corresponds with the customer account and used for added security. According to various embodiments, some or all of the information in the first code may be encrypted. The encryption key may be stored on the provider institution computing system 106 such that the information in the first code may be decrypted and utilized during the account opening process 1700. For example, the security code and/or the authentication code may be encrypted such that the customer device 104 cannot determine the encrypted codes. The customer device 104 may subsequently provide the encrypted codes to the provider institution computing system 106 such that the provider institution computing system 106 can confirm the security code and/or the authentication code before opening the customer account.

At process 1725, a customer confirmation is received. For example, the customer may complete the terms and conditions and/or the customer consent form within the browser or application on the customer device 104 and the customer device 104 may send the completed terms and conditions and consent or a confirmation of completed terms and conditions to the provider institution computing system 106. Further, the customer may accept or decline the one or more offer codes or promotional codes included in the preliminary account information.

Further, process 1725 may include receiving one or more unique identifiers. The provider institution computing system 106 may determine that the one or more unique identifiers corresponds with the preliminary account information before opening an account. For example, the provider institution computing system 106 may receive the security code and/or the authentication code from the customer device 104 and determine that the security code and/or the authentication code correspond with the customer account. The security code and/or the authentication code may be encrypted and the provider institution computing system 106 may store an encryption key such that the provider institution computing system 106 can confirm the security code and/or the authentication code before opening the customer account. Process 1725 may further include receiving the additional account information completed within the browser or application on the customer device 104.

Process 1725 may further include receiving a customer contact confirmation. For example, a customer contact confirmation request (e.g., an email, phone number, and/or text message) may be provided to an email address or phone number identified in the preliminary account information. The customer may submit a customer confirmation request in response to the customer contact confirmation request (e.g., by selecting a link in the email or text message).

At process 1730, the customer account is opened. As discussed herein, the customer account may be opened in real time or substantially real time, without additional authentication needed. For example, the authentication can be completed at process 1715 and the authentication code can be provided to the provider institution computer system 106 by the customer device 104 such that further authentication does not need to be completed. Once the account is open, the customer device 104 may complete additional account opening operations (e.g., a streamlined enrollment), such as agreeing to online access, setting a card pin number, enrolling in a mobile/digital wallet, enrolling in a paperless enrollment program, providing funding, applying for additional financial services, and/or any other account related activities.

According to various embodiments, the customer may receive a summary after the account is opened. For example, the summary may be provided as a digital message (e.g., text message, email, web notification, message on the client application 132, etc.). Additionally or alternatively, a printed summary may be provided to the customer if the customer is at a local branch.

According to various embodiments, the customer may be a new customer or an existing customer. The customer may include joint applications. The customer may be an adult or a minor. The customer may or may not have a Social Security Number or Individual Taxpayer Identification Number. The customer may be a resident or a non-resident alien (relative to the U.S.). The customer may be an entity, such as a business. The process 1700 may be completed in English or any other language.

Referring now to FIG. 18, a flow diagram of another account opening process 1800 is shown, according to an example embodiment. The account opening process 1800 may be utilized by a customer to facilitate opening a customer account. For example, the account opening process 1700 may be utilized by the customer to assist the customer open an account while meeting with a provider agent (e.g., in person, virtually, etc.). In some embodiments, the account opening process 300 may be performed by the customer device 104, the provider institution computing system 106 and/or the provider agent device 254. It should be appreciated that the account opening process 1800 may be performed in any order and certain processes may be omitted.

The account opening process 1800 may involve two or more parties, such as a customer (e.g., a user) and a provider agent (e.g., an agent). As discussed further, the customer and the provider agent may interact with one another for some or all of the account opening process 1800. According to various embodiments, the customer operates a customer device 104 and the provider agent operates the provider agent device 254. The customer device 104 and the provider agent device 254 may not be in direct communication with one another. Further, the customer device 104 and/or the provider agent device 254 may communicate with the provider institution computing system 106. According to various embodiments, the account opening process 1800 is performed entirely by the customer device 104.

Process 1810 includes capturing a first code. For example, the customer device 106 may capture the first code generated by the provider agent device 254 at process 1720. For example, the first code may be generated by the provider agent device 254 in response to receiving the preliminary account information and/or authenticating the preliminary account information. The first code may be displayed on the provider agent device 254 and captured by the customer device 106, as described herein. In this sense, the customer device 106 and the provider agent device 254 may not be in direct communication. Additionally or alternatively, the first code may be entered into the customer device via the input/output device 136 (e.g., the code may be provided to the customer via an audio medium). Further, the first code may be provided to the customer device 104 via a digital medium. Further, the first code may be captured by the customer device 104 via NFC.

As discussed further herein, when the customer device 104 captures or scans the first code, a browser or a corresponding application (e.g., the client application 132) may be launched on the customer device 104. The first code may be embedded with code to cause launching or activation of the client application 132, which may be a specific application (e.g., a mobile banking application) or a web browser application. Alternatively, the first code may be a URL that, when captured by the customer device 104 (e.g., entered using the input/output device 136, captured via a camera of the customer device 104, etc.) launches a browser. The browser may display a website with additional account application instructions. Further, the browser may direct a customer to download an application (e.g., the client application 132 when it is embodied as a specific application and not the web browser) on the customer device 104.

The first code may be embedded with data (e.g., unique identifiers). For example, the first code may include one or more unique identifiers that include some or all the preliminary account information. In this sense, the first code may be specific to the customer. According to various embodiments, the first code includes preliminary account information such that capturing the first code on the customer device 104 may launch a browser or an application in response to capturing the first code thereby causing a display of a graphical user interface comprising one or more fillable fields with at least one of the one or more fillable fields populated with preliminary account information from the captured first code. Some or all the account information may be specific to a user account and therefore may accelerate the account opening process.

According to various embodiments, the browser or application may allow the user to input additional account information. For example, the browser or application may include fields that allow a user to enter sensitive information the customer (e.g., account passwords, identification numbers such as social security numbers, account numbers, etc.). Further, the browser or application may include fields that allow the customer to customize a card (e.g., a credit card, a debit card, etc.). The browser or application may include a field to enter a W9 certification. Furthermore, the browser or application may include a field that allows the customer to link another account to the user account (e.g., for funding of the new account).

Furthermore, the first code may include a customer confirmation request. For example, capturing the first code may cause a customer confirmation request (e.g., a user confirmation request) to be launched on the customer device 104 (e.g., within the browser or the application. The customer confirmation request may include a terms and conditions area that may display some or all of the terms and conditions of the provider institution. Further, there may be a consent area that the customer may use to consent and opt into the terms and conditions. For example, a GUI may be generated from within the browser or application on the customer device 104. The GUI may include the terms and conditions and a customer confirmation box (see, e.g., FIG. 30). The customer may click a check box to confirm the customer agrees to the terms and conditions. The confirmation may then be provided to the provider institution computing system 106.

Furthermore, the first code may include a security code and/or an authentication code. The security code and the authentication code may facilitate opening the user account in real time (e.g., in response to providing the security code and the authentication code to the provider computing system 106) without further need to authenticate the identity of the customer, as described further herein. The security code and/or the authentication code may be encrypted such that the security code and authentication code are hidden from the customer device 104.

Process 1820 includes providing preliminary account information. For example, the customer device 104 may provide preliminary account information to the provider institution computing system 106. The preliminary account information may include the preliminary account information included in the first code and/or additional preliminary account information entered into the customer device 104.

Process 1820 may include providing additional information (e.g., unique identifiers) included in the first code. For example, the security code and/or the authentication code may be provided to the provider institution computing system 106. Process 1802 may further include providing the customer confirmation (e.g., the completed terms and conditions and consent or a confirmation of completed terms and conditions) to the provider institution computing system. For example, a GUI may be generated from within the browser or application on the customer device 104. The GUI may include the terms and conditions and a customer confirmation box (see, e.g., FIG. 30). The customer may click a check box to confirm the customer agrees to the terms and conditions. The confirmation may then be provided to the provider institution computing system 106.

Process 1830 includes accessing the account. For example, the customer may access the customer account on the customer device 104 (e.g., within the client application 132) in response to the preliminary account information, the unique identifiers, the customer confirmation, and/or any other information provided to the provider computing system. After accessing the account, the customer may provide further onboarding data, such as agreeing to online access, setting a card PIN value, enrolling in a mobile wallet, enrolling in a paperless enrollment program, and/or any other account related activities.

Referring now to FIG. 19, a flow diagram of another account opening process 1900 is shown, according to an example embodiment. The account opening process 1700 may be utilized by a provider institution to facilitate opening a customer account. For example, the account opening process 1700 may be utilized by a provider agent to assist a customer open an account while the two parties meet (e.g., in person, virtually, etc.) without the need for the customer to access the customer device 104. In some embodiments, the account opening process 300 may be performed by the customer device 104, the provider institution computing system 106 and/or the provider agent device 254. It should be appreciated that the account opening process 1900 may be performed in any order and that certain processes may be omitted.

The account opening process 1900 may involve two or more parties, such as a customer (e.g., a user) and a provider agent (e.g., an agent) associated with the provider institution described herein. As discussed further, the customer and the provider agent may interact with one another for some or all of the account opening process 1900. According to various embodiments, the customer operates a customer device 104 and the provider agent operates the provider agent device 254. The customer device 104 and the provider agent device 254 may not be in direct communication with one another. Further, the customer device 104 and/or the provider agent device 254 may communicate with the provider institution computing system 106.

Process 1910 includes receiving preliminary account information. For example, the provider agent device 254 may receive preliminary account information (e.g., account information, customer information, user information, etc.) via the input/output device 236. Process 1910 may be the same or similar to process 1710 described above.

Process 1915 includes authenticating the preliminary account information. For example, the preliminary account information that is received by the provider institution computing system 106 and/or the provider agent device 254 at process 306 may be authenticated by the provider institution computing system 106 and/or the provider agent device 254. Process 1915 may be the same or similar to process 1715 described above.

At process 1920, a customer confirmation is received. For example, the customer may complete the terms and conditions and/or the customer consent form on the provider agent device 254. According to an example embodiment, the terms and conditions and/or the customer consent form are printed off for the customer to review and complete. In another embodiment, a customer confirmation request may be displayed on the provider agent device 254 and presented to the customer. The customer confirmation request may include a terms and conditions area that may display some or all of the terms and conditions of the provider institution. Further, there may be a consent area that the customer may use to consent and opt into the terms and conditions. The customer may utilize the input/output device 236 of the provider device to complete the customer confirmation request and the completed customer confirmation may be provided to the provider institution computing system 106. For example, the customer may use a pin pad to complete the customer confirmation. According to various embodiments, the pin pad may be a part of the provider agent device 254 or coupled to the provider agent device 254.

Process 1920 may include receiving a customer contact confirmation. For example, a customer contact confirmation request (e.g., an email or text message) may be provided to an email address or phone number identified in the preliminary account information. The customer may confirm his or her email address or phone number by selecting a link in the email or text message. The customer may complete a customer confirmation request by selecting a link in the email or text message.

At process 1925, the customer account is opened. Process 1925 may include creating an account number, storing the account number in the account database 146, and associating the account number with account information associated with the customer. As discussed herein, the customer account may be opened in real time, without additional authentication needed. For example, the authentication can be completed at process 1915 and the authentication code can be provided to the provider institution computer system 106 by the provider agent device 254 such that further authentication does not need to be completed. Once the account is open, the customer may access his or her account using the customer device 104.

At process 1930, additional onboarding data may be received. For example, additional onboarding data may be received from the customer device 104. For example, the customer may access the customer account on the customer device 104 (e.g., within the client application 132) in response to the preliminary account information, the unique identifiers, the customer confirmation, and/or any other information provided to the provider computing system. After accessing the account, the customer may provide further onboarding data, such as agreeing to online access, setting a card pin number, enrolling in a mobile wallet, enrolling in a paperless enrollment program, and/or any other account related activities.

Referring now to FIG. 20, a flow diagram of another account opening process 2000 is shown, according to an example embodiment. The account opening process 2000 may be utilized by a provider institution to facilitate opening a customer account. For example, the account opening process 2000 may be utilized by a provider agent to assist a customer open an account while the customer visits a local branch. According to various embodiments, the account opening process 200 may be utilized by a plurality of customers at a particular local branch having a limited number of provider agents. In some embodiments, the account opening process 300 may be performed by the customer device 104, the provider institution computing system 106 and/or the provider agent device 254. It should be appreciated the account opening process 2000 may be performed in any order and that certain processes may be omitted.

At process 2010, a first code is generated. Generating the first code may be done by the provider institution computing system 106 and/or the provider agent device 254. In some embodiments, the first code may be generated using the provider application 232. In further embodiments, the first code may be generated by a third party and provided to the provider institution for distribution. The first code may be generated in a similar manner as the first code generated in process 302 described above.

For example, the agent of the provider institution may display written account application instructions on a poster, brochure, presentation, handout, digital display, etc. For example, the agent of the provider institution may display a poster within a bank location. The poster may include the first code that is capable of being captured by a customer device 104 along with account application instructions that instruct the customer how to use/access the code to open an account. In one example embodiment, the account application instructions may instruct the customer to download an application (e.g., the client application 132). For example, the customer may utilize a camera, which may be accessible by the client application 132, on the customer device 104 to scan a QR code on the poster.

In another example, the account application instructions may instruct the customer to use an image capture device (e.g., a camera) on the customer device 104 to capture the first code. When the customer device 104 captures or scans the first code, a browser or a corresponding application (e.g., the client application 132) may be launched on the customer device 104. The first code may be embedded with computer code/instructions to cause launching or activation of the client application 132, which may be a specific application (e.g., a mobile banking application) or a web browser application. Alternatively, the first code may be a URL that, when entered into the customer device 104 launches a browser. The browser may display a website with additional account application instructions. Further, the browser may direct a customer to download an application (e.g., the client application 132 when it is embodied as a specific application and not the web browser) on the customer device 104.

Further, the first code may be captured by the customer device 104 via NFC. For example, the first code may be stored on an NFC device within a local branch such that the first code is sent to the customer device 104 via NFC tap, such that the customer device 104 captures the first code. Using short-range wireless transmission protocols add security to the process and enable the process to be specific to event/limited to reduce bandwidth constraints.

In certain embodiments, the client application 132 (e.g., a browser and/or a corresponding application), may be launched on the customer device 104 in response to the first code being captured. For example, when the first code is captured, a web browser may be launched, and the customer device 104 may be directed to a webpage. The web page may be operated by the provider institution. For example, the web page may be a virtual banking website. Further, an application, such as a mobile application, may be launched on the customer device 104 in response to the first code being captured. For example, a mobile banking application operated by the provider institution (e.g., the client application 132) may be launched on the customer device 104 in response to the first code being captured. Further, a request to download an application may be presented on the customer device 104 in response to the first code being captured on the customer device 104. For example, an application download platform (e.g., the Apple App Store®, the Android Marketplace®, the Google Play® store, etc.) may be launched on the customer device 104 in response to the first code being captured. The customer may then be prompted to download the mobile banking application on the customer device 104. In some embodiments, the customer device may scan a QR code, which may launch an application download platform, which may prompt the customer to download a mobile banking application on the customer device 104, and once downloaded, the mobile banking application may be launched.

In some embodiments, process 2010 may include identifying the location of the customer device 104. The customer device 104 may use a GPS, or other location identification method, to determine the location of the customer device 104. For example, the customer device 104 may use a GPS, or other location identification method, to identify the local branch location as well as the location or approximate location of the customer device 104. In some embodiments, the location of the customer device 104 may be used in conjunction with stored location information regarding the branch location. For example, when the customer device 10 is within a predefined range of a branch location, a prompt may be sent to the customer device 104 to capture the first code. Alternatively, the first code may be transmitted as a push notification to the customer device 104. In some embodiments, the first code may be transmitted as a push notification to a customer device 104 that is operated by a customer that is an existing customer with the provider institution such that the provider institution may provide the customer device 104 with additional products and/or services.

In certain embodiments, the first code may include one or more unique identifiers. For example, the location of a local branch may be embedded as one or more unique identifiers within the first code (e.g., as latitude and longitude coordinates, as a specific location value assignment (e.g., ABCXXX2426 refers to Branch A in Boise, ID), etc.). Further, the identity of an agent of the provider institution may be included as a unique identifier in the first code. In some embodiments, the customer may not be aware that this information is embedded within the first code. The unique identifiers may be used later in the account opening process 2000. For example, when the customer confirmation is received by the provider institution computing system 106 from the customer device 104 (see process 2045 below), the customer confirmation may include one or more unique identifiers that may be compared to the one or more unique identifiers in the first code as an added layer of security, as will be discussed further herein. Further, the one or more unique identifiers may be used to automatically generate preliminary account application information, as will be discussed further with respect to process 2015 and process 2035 below. Further, when the first code is captured by the customer device 104, the customer device 104 may use a GPS or other location identification method to determine a position of the customer device 104, and the location of the customer device 104 may be used as a unique identifier. The one or more unique identifiers may be used later in the account opening process 2000, as will be discussed further herein.

At process 2015, preliminary account information is received. For example, the customer device 104 may send preliminary account application information to the provider institution computing system 106 and/or the provider agent device 254. The preliminary account application information may include information requested as a part of the account application instructions. The preliminary account application information may include information needed to open an account with the provider institution. For example, the preliminary account application information may include information required by the provider institution's CIP. Process 2015 may be the same or similar to process 306 described above.

At decision 2020, a determination is made as to whether an agent (e.g., a provider agent) is available to meet with the customer. According to various embodiments, the customer may indicate on the customer device 104 whether or not an agent is available. For example, the browser or application may cause a notification to be displayed on the customer device 104 asking the customer if there is an agent available such that the customer may confirm whether or not an agent is available.

According to various embodiments, the provider institution computing system 206 may determine whether or not an agent is available. For example, one or more provider agents may be identified using one or more of the unique identifiers. For example, the first code may include a unique identifier that identifies one or more provider agents corresponding with the local branch. Further, the location of the customer device 104 and/or the location of the first code may be included in the received preliminary account information (e.g., as a unique identifier) and the location may be utilized by the provider institution computing system 106 to determine one or more agents corresponding with the location.

According to various embodiments, the provider institution computing system 106 may access one or more calendars that depicts the schedules of the one or more agents to determine which agents are available.

Additionally or alternatively, the provider institution computing system 106 may ping one or more provider agent devices 254 located at the branch to determine which provider agents are using a provider agent device 254 and/or not currently assisting another customer.

According to various embodiments, a notification could be provided to one or more provider agent devices 106. The notification may ask the provider agent to confirm the provider agent's availability (e.g., current availability or future availability). By confirming which provider agent is available, processing resources may be reduced by only sending the notification to provider agents that are working and/or associated with a particular local branch.

If a provider agent is not available, an appointment request may be received at process 2025. For example, upon determining that an agent is not available, an appointment request form (e.g., a specific graphical user interface or another electronic document or other document that enables the customer to request an appointment, such as a day of the appointment, expertise of the agent needed for the appointment, etc.) may be provided to the customer device 104 such that the customer can schedule a future appointment. The customer device 104 may then be used to send the appointment request, which may be received by the provider institution computing system 106.

If a provider agent is available, the customer may be instructed to see the available agent and the preliminary account information may be retrieved at process 2030. For example, the preliminary account information received at process 2015 may be retrieved by the provider agent device 254. According to various embodiments, a notification may be displayed on the customer device 106 that includes identifying information for the available agent (e.g., name, desk number, office location, etc.).

Process 2030 may further include the provider agent device 254 receiving additional customer account information. For example, process 2030 may be similar to process 1710 described above.

Process 2035 includes authenticating the preliminary account information. For example, the preliminary account information that is received by the provider institution computing system 106 and/or the provider agent device 254 at process 306 may be authenticated by the provider institution computing system 106 and/or the provider agent device 254. As discussed above, authenticating the preliminary account information may include performing a risk assessment. That is, the provider institution or entity may analyze the preliminary account information received at process 306 and determine whether additional processes are needed to verify the customer's identity. For example, the provider institution or entity may cross-reference information submitted by the customer in the account application response with other information available to the provider institution (e.g., information from a separate account with the provider institution, information provided by a consumer credit reporting agency, etc.) and perform a risk assessment regarding verifying the identity of the customer (i.e., an assessment regarding whether the customer has the identity purported to have).

According to various embodiments, process 2035 includes manually checking a customer's form of identification (e.g., passport, driver's license, birth certificate, Social Security card, student ID, credit card, debit card, insurance card, etc.) by one or more agents of the provider institution. For example, the customer may show the provider agent of the provider institution the customer's form(s) of identification to verify the customer's identity. The provider agent may cross-reference the information in the customers form(s) of identification with the preliminary account information received by the provider agent device 254 to verify the customer's identity. In response to the identification being authenticated and the customer's identity being verified, the employee may cause an authentication code to be included with the preliminary account information. The authentication code may pre-authorize an account to be opened in the customer's name, as discussed further herein. For example, the customer then accesses his or her account once the authentication code is received and verified by the provider institution computing system 106.

Process 2040 includes generating a second code. For example, the second code may be generated by the provider agent device 254 in response to receiving the preliminary account information and/or authenticating the preliminary account information. Process 2040 may be similar or the same as process 1720 discussed above. For example, the second code may be the same or similar to the first code discussed above with respect to FIGS. 17 and 18.

At process 2045, a customer confirmation is received. For example, the customer may complete the terms and conditions and/or the customer consent form on the provider agent device 254. For example, a GUI may be generated from within the browser or application on the customer device 104. The GUI may include the terms and conditions and a customer confirmation box (see, e.g., FIG. 30). The customer may click a check box to confirm the customer agrees to the terms and conditions. The confirmation may then be provided to the provider institution computing system 106. For example, a customer confirmation request may be displayed on the provider agent device 254 and presented to the customer. The customer confirmation request may include a terms and conditions area that may display some or all of the terms and conditions of the provider institution. Further, there may be a consent area that the customer may use to consent and opt into the terms and conditions. The customer may utilize the input/output device 236 of the provider device to complete the customer confirmation request and the completed customer confirmation may be provided to the provider institution computing system 106.

Process 2045 may include receiving a customer contact confirmation. For example, a customer contact confirmation request (e.g., an email or text message) may be provided to an email address or phone number identified in the preliminary account information. The customer may confirm his or her email address or phone number by selecting a link in the email or text message. The customer may complete a customer confirmation request by selecting a link in the email or text message.

At process 2050, the customer account is opened. As discussed herein, the customer account may be opened in real time, without additional authentication needed. For example, the authentication can be completed at process 1915 and the authentication code can be provided to the provider institution computer system 106 by the provider agent device 254 such that further authentication does not need to be completed. Once the account is open, the customer may access his or her account using the customer device 104.

Referring now to FIG. 21, a flow diagram of another account opening process 100 is shown, according to an example embodiment. In some embodiments, the account opening process 300 may be performed by the customer device 104, the provider institution computing system 106 and/or the provider agent device 254. It should be appreciated the account opening process 2100 may be performed in any order and that certain processes may be omitted.

At process 2110, a first code is captured. Capturing the first code may be done by the customer device 104. In some embodiments, the first code may be generated using the provider application 232. In further embodiments, the first code may be generated by a third party and provided to the provider institution for distribution. For example, the first code generated at process 2010 may be the first code captured at process 2110.

At process 2115, preliminary account information is provided. For example, the customer device 104 may send preliminary account application information to the provider institution computing system 106 and/or the provider agent device 254. The preliminary account application information may include information requested as a part of the account application instructions. The preliminary account application information may include information needed to open an account with the provider institution. For example, the preliminary account application information may include information required by the provider institution's CIP. For example, the preliminary account information provided at process 2115 may be received at process 2015.

At decision 2120, a determination is made as to whether an agent (e.g., a provider agent) is available to meet with the customer. Decision 2120 may be the same or similar to decision 2020 described above.

If a provider agent is not available, an appointment request may be provided at process 2125. For example, upon determining that an agent is not available, an appointment request form may be provided to the customer device 104 such that the customer can schedule a future appointment. The customer device 104 may then be used to send the appointment request, which may be received by the provider institution computing system 106. The appointment request provided at process 2125 may be the appointment request received at process 2025.

If a provider agent is available, the customer may be instructed to see the available agent and the preliminary account information may be retrieved and/or additional account information may be provided and entered into the provider agent device 254 as described above with respect to process 2030. Further, the preliminary account information may be authenticated as described above with respect to process 2035 and a second code may be generated as described above with respect to process 2040.

Process 2130 includes capturing a second code. The second code may be captured by the customer device 104. For example, process 2130 may be similar to process 1810 described above. For example, the second code captured at process 1810 may be the second code generated at process 2040. For example, the second code may be the same or similar to the first code discussed above with respect to FIGS. 17 and 18.

At process 2145, a customer confirmation is provided. For example, the customer may complete the terms and conditions and/or the customer consent form on the provider agent device 254. For example, a customer confirmation request may be displayed on the provider agent device 254 and presented to the customer. The customer confirmation request may include a terms and conditions area that may display some or all of the terms and conditions of the provider institution. Further, there may be a consent area that the customer may use to consent and opt into the terms and conditions. The customer may utilize the input/output device 236 of the provider device to complete the customer confirmation request and the completed customer confirmation may be provided to the provider institution computing system 106.

Process 2145 may include providing a customer contact confirmation. For example, a customer contact confirmation request (e.g., an email or text message) may be provided to an email address or phone number identified in the preliminary account information. The customer may confirm his or her email address or phone number by selecting a link in the email or text message. The customer may complete a customer confirmation request by selecting a link in the email or text message.

At process 2150, the customer account is accessed. For example, the customer may access the customer account on the customer device 104 (e.g., within the client application 132) in response to the preliminary account information, the unique identifiers, the customer confirmation, and/or any other information provided to the provider computing system. After accessing the account, the customer may provide further onboarding data, such as agreeing to online access, setting a card pin number, enrolling in a mobile wallet, enrolling in a paperless enroll, etc.

Referring now to FIG. 22, a GUI 2200 for inputting preliminary account application information is shown, according to an example embodiment. For example, the GUI 2200 may be displayed on the provider agent device 254 (e.g., as a part of process 1710, process 1910, process 2030, etc.). According to various embodiments, the GUI 2200 displays current customer information in the preliminary account information fields 2210. For example, the provider agent may use the provider agent device 254 to search for an existing customer profile and pull up the customer information for display in the preliminary account information fields.

Referring now to FIG. 23, a GUI 2300 for inputting preliminary account application information is shown, according to an example embodiment. For example, the GUI 2300 may be displayed on the provider agent device 254 (e.g., as a part of process 1710, process 1910, process 2030, etc.). According to various embodiments, the GUI 2300 displays new customer information in the preliminary account information fields 2310. For example, the provider agent may use the provider agent device 254 to enter in preliminary account information provided by the customer.

Referring now to FIG. 24, a GUI 2400 for inputting preliminary account application information is shown, according to an example embodiment. For example, the GUI 2400 may be displayed on the provider agent device 254 (e.g., as a part of process 1710, process 1910, process