Systems and methods for instant bank card issuance

Systems and methods for instant issuing of a transaction card, controlling issuing of the instant transaction card, and customization of the transaction card. A system includes at least one processor and a storage medium storing instructions that, when executed by the one or more processors, cause the at least one processor to perform operations including receiving a request to issue a card and directing the customer to insert an identification card. Proceeding with capturing identification and biometric data identifying the customer and verifying the captured identification and biometric data. The operations also include determining whether a combination of the available customer data and the received biometric data is sufficient to verify customer identity. When the combination data are sufficient to verify customer identity, the operations further include issuing a transaction card. The operations further include capturing an image of the customer and issuing a customized transaction card to the customer.

TECHNICAL FIELD

The present disclosure generally relates to computerized systems and methods for instant bank card issuance. In particular, embodiments of the present disclosure relate to inventive and unconventional systems for instant issuing of a transaction card, controlling issuing of the instant transaction card, and customization of the transaction card.

BACKGROUND

Currently, if a new or replacement transaction card is desired it is necessary to apply through a bank and wait for the card to be received in the mail. Transaction cards may include credit cards, debit cards, loyalty program cards, ATM cards, or any other type of card used conducting a commercial transaction, including cards having an EMV chip. An application for a new transaction card may be submitted in person or electronically, but regardless of how the application is received, the applicant must wait until the card is received in the mail. Mailing a card takes time, and customer is unable to use the card until it is received and activated. Even if an existing card is compromised or stolen, customers are forced to wait until a replacement card is delivered to them in the mail.

Current approaches exhibit a number of problems. Cards are typically mailed to the billing address of the customer, regardless of from where the application is made. Thus, if the customer is traveling, he will not be able to receive a new or replacement card until he returns to the location of the billing address. Card issuers therefore lose money every day customer is using another bank card. Thus, card issuers often incur the extra expense of overnight delivery.

Therefore, there is a need for improved methods and systems for instant issuing of a transaction card.

SUMMARY

One aspect of the present disclosure is directed to a system for instant issuing of a transaction card, including at least one processor; and at least one memory storing instructions that, when executed by the at least one processor cause the system to perform operations. The operations include receiving a customer request to issue a transaction card and directing the customer to insert an identification card. The operations also include capturing identification data from the identification card and capturing biometric data identifying the customer. The operations further include verifying the captured identification and biometric data; and if verification is successful, ejecting the identification card and issuing a transaction card.

Another aspect of the present disclosure is directed to a system for controlling issuing of an instant transaction card, including at least one processor; and at least one memory storing instructions that, when executed by the at least one processor cause the system to perform operations. The operations include receiving data captured by a card issuing system and determining whether customer data corresponding to the received data is available in an internal database. When customer data corresponding to the received captured data is available in the internal database, the operations also include determining whether the available customer data is sufficient to verify customer identity. When the available customer data is not sufficient to verify customer identity, The operations also receiving biometric data from the card issuing system. The operations further include determining whether a combination of the available customer data and the received biometric data is sufficient to verify customer identity. When the combination data are sufficient to verify customer identity, the operations further include sending the card issuing system instructions to issue a transaction card.

Yet another aspect of the present disclosure is directed to customization of a transaction card, including at least one processor; and at least one memory storing instructions that, when executed by the at least one processor cause the system to perform operations. The operations include receiving a customer request for customization of the transaction card and directing a customer to move to a designated area. The operations also include capturing an image of the customer; displaying the image to the customer; and requesting customer approval of the image. Upon receiving the approval, the operations further include issuing a customized transaction card to the customer.

Other systems, methods, and computer-readable media are also discussed herein.

DETAILED DESCRIPTION

Reference will now be made in detail to exemplary embodiments, discussed with regards to the accompanying drawings. In some instances, the same reference numbers will be used throughout the drawings and the following description to refer to the same or like parts. Unless otherwise defined, technical and/or scientific terms have the meaning commonly understood by one of ordinary skill in the art. The disclosed embodiments are described in sufficient detail to enable those skilled in the art to practice the disclosed embodiments. It is to be understood that other embodiments may be utilized and that changes may be made without departing from the scope of the disclosed embodiments. Thus, the materials, methods, and examples are illustrative only and are not intended to be necessarily limiting.

Embodiments of the present disclosure are directed to systems and methods configured for instant issuing of a transaction card, controlling issuing of the instant transaction card, and customization of the transaction card.

FIG. 1is a schematic block diagram of an exemplary embodiment of a system100for performing instant issuing of a transaction card, controlling issuing of the instant transaction card, and customization of the transaction card. As shown inFIG. 1, system100may include a variety of components and subsystems, each of which may be connected to one another. System100is not limited to the depicted exemplary embodiment and may comprise additional computerized systems, working in tandem, and connected via network140. The components and subsystems may also be connected to one another via a direct connection, for example, using a cable.

System100includes a card issuing system110, a third party verification system120, and a financial service provider system130respectively comprising processors111,121, and131; memories112,122, and132; and I/O interfaces117,124, and134. Processors111,121,131may comprise a microprocessor, including a central processing unit (CPU), a graphics processing unit (GPU), or other electronic circuitry capable of carrying out the instructions of a computer program by performing the operations specified by instructions stored in a memory112,122,132. Alternatively, or concurrently, processors111,121,131may comprise one or more special-purpose devices built according to embodiments of the present disclosure using suitable circuit elements, e.g., one or more application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or the like. Memories112,122,132may comprise volatile memory, such as random-access memory (RAM), a non-volatile memory, such as a hard disk drive, a flash memory, or the like, or any combination thereof.

Card issuing system110includes a biometric system113. Biometric system113, may include any suitable hardware or software solutions for capture and verification of various types of biometric information such as, for example, signature recognition, fingerprint recognition, voice verification/authentication, vein recognition, typing recognition, scent/odor recognition, hand geometry recognition, gait recognition, finger geometry recognition, fingerprint recognition, face recognition, iris/retina recognition, etc.

Card issuing system110further includes a blank card storage114. Blank card storage114may comprise any suitable hardware for storing blank transaction cards.

Card issuing system110further includes a card reader115having any suitable hardware to read information on a transaction card. Card reader115may further include necessary technology to employ multiple levels of security, e.g. black light detection, high-resolution scanning, etc.

Card issuing system110further includes a card printer116having any suitable hardware for production of transaction cards. EMV chips on transaction cards may be pre-encoded or encoded by the card printer116.

Third party verification system120and financial service provider system130further respectively include databases125and135. Databases125and135may each include any suitable hardware or software solutions for an organized collection of data.

I/O interfaces117,124,134may comprise any suitable hardware or software solution for input/output of data. I/O operations may be accomplished through a wide assortment of external devices that provide a means of exchanging the data via inputs and outputs between the external environment and respective subsystem110,120,130.

System100further includes a network140. Network140may be any type of network that facilitates communications and data transfer between components of a system environment. Network may be a Local Area Network (LAN), a Wide Area Network (WAN), such as the Internet, and may be a single network or a combination of networks. Further, network140may reflect a single type of network or a combination of different types of networks, such as the Internet and public exchange networks for wireline and/or wireless communications. Network140may use cloud computing technologies. Network is not limited to the above examples and system100may implement any type of network that allows the components and entities (not shown) included inFIG. 1to exchange data and information.

FIG. 2is a flow chart of a process200for issuing a transaction card to a customer. Process200starts at step210by receiving a customer request for issuance of a new or replacement transaction card. The customer request may be based on a new application or on an earlier existing application. In the event the request is based on an earlier application, the customer may be prompted for a reference number. The request must identify whether the customer is seeking to open a new transaction card or is seeking replacement of an existing card. Replacement may be requested due to damage, loss, or suspected fraud on the existing card. Alternatively, replacement may be requested if customer is unhappy with the current design of the card and would like to have a card customized, as described in more detail inFIG. 5.

Process200then proceeds to step220. In step220, system100receives customer-identifying information. Customer-identifying information may include data from an ID card, such as driver's license, school ID, passport, etc. Customer-identifying information is not limited to the information received from the ID card and may further include biometric and behavioral identifying information.

Process200then proceeds to step230, where system100analyzes the customer identifying information. Analysis may be performed based on the information stored in database135of the financial service provider system130. Based on the result of the analysis, it may be determined that financial service provider system130does not contain enough information, and third party verification system120may be contacted to provide additional information necessary for the next step240, verification.

In step240, system100verifies the customer identification information. If the result of the analysis performed in step230indicates that additional information is required for verification, third party verification system120may be contacted. For example, a Department of Motor Vehicles (DMV) database may be contacted to verify driver's license information, or a partner bank may be contacted for additional information regarding the customer.

At step250it is determined whether verification of the customer is successful. If so (step250=YES), process200proceeds to step260, where a new transaction card is issued. In the event of reissuance, an old transactional card may be collected.

In the event that verification is not successful (step250=NO), process200proceeds to step270where if an ID provided by the customer is determined to be fraudulent, the ID may be collected, a fraud department may be alerted, and law enforcement may be contacted. All identification information collected during process200is further stored for future use by the financial service provider system130.

FIG. 3is a flow chart of a process300for issuing a new or replacement transaction card by the card issuing system110. Process300starts at step310by receiving customer request for issuance of a new/replacement transaction card. The request is received by I/O Interface117of the card issuing system110. This step is similar to the step210of process200described earlier and is consistent with the earlier disclosure.

Process300then proceeds to step320. In step320, card issuing system110directs a customer to insert an identification card in a card reader115. Insertion directions may be displayed via I/O Interface117. Directions may include types of acceptable identifications, required card orientation, location of the card reader, etc. Directions may change based on the unsuccessful attempts to insert an identification card. For example, if customer inserts an identification card upside down, directions might be altered specifically to guide the customer to flip an identification card before reinserting it into a card reader115.

Process300then proceeds to step330, where the card issuing system110captures ID data from the identification card by, for example, card reader115. Data may include a scanned image of the identification card and or information displayed on the card, such as legal name, residential address, birth date, gender, driver's license or identification number, digital front-facing photograph, signature, etc. ID data may further include any information embedded in the identification card, e.g. biometric information, security codes, etc. Capture of ID data may vary based on the type of identification card. A security level of the identification card may also be recorded. For example, a driver's license will have a higher security level as compared to a student ID. Different states have different standards for driver's licenses and security level may vary accordingly. Similarly, newer Real ID licenses will have a higher security standard compare to earlier issued licenses. Various security features may be assessed during the capture process.

Card reader115may be equipped with the necessary technology to identify multiple levels of security, by capturing overt features easily visible to the naked eye, like a color cardholder photo or signature, and covert features visible only with the use of additional equipment, such as UV light, and high magnification to identify microscopic features often used to differentiate between legitimate identification cards and fake identification cards. Other types of security features include micro text, ghosted images, holographic background images, laminates with holographic images, embedded technology, UV text or images, official seals, thermochromic printing, opacity printing, embossed printing, etc.

Process300then proceeds to step340, where the card issuing system110directs a customer to stand in a designated area. Directions may be displayed via I/O Interface117. Directions may include arrows, a schematic outline of the designated area, voiced guidance, etc. Directions may change based on the unsuccessful attempts to stand in the designated area. For example, if customer is standing too close, card issuing system110may audibly ask customer to take a step back. Another example is if a voiceprint is being captured, card issuing system110may ask customer to repeat the phrase several times with different volumes.

Process300then proceeds to step350, where the card issuing system110captures biometric data identifying the customer. I/O Interface117of card issuing system110may include necessary technology to perform the capture. Behavioral characteristics may be also captured. As used herein, behavioral characteristics may relate to a person's pattern of behavior including, for example, typing rhythm, gait, word choice, etc. Data capture is further explained below with respect toFIG. 3. For example, if the identification card used in steps310-330contains a photo, a customer may be asked to take a “selfie” for verification.

Process300then proceed to step360, where card issuing system110sends data captured in steps330and350for processing to financial service provider system130. This step may be performed multiple times, as necessary. For example, data may first be sent immediately after step330and again after step350.

Process300then proceeds to step370, where the card issuing system110receives verification data from financial service provider system130. Financial service provider system130may have contacted third party verification system120as described in the process200to confirm verification information. Verification data indicates whether verification of the customer passed or failed380.

If verification is successful, process300proceeds to step381, where card issuing system110ejects the identification card from the card reader115. Step282where additional information (e.g., issuance information, identification card details, etc.) is exchanged with the financial service provider system130. Process300concludes a step383, where a new card is issued to the customer.

If verification fails, process300proceeds to step385, where the card issuing system110may eject the identification card. Alternatively, if the identification card is determined to be fraudulent, the identification card may be collected, a fraud department alerted, and law enforcement contacted.

FIG. 4is a flow chart of a process400for controlling issuance of an instant transaction card by financial service provider system130. Process400starts at step410by receiving captured data from card issuing system110. The process of capturing data by the card issuing system110is as described earlier in process300ofFIG. 3. Types of captured data are as described earlier and may include data captured from an identification card of a customer as well as biometric data captured by card issuing system110.

Process400then proceeds to step420. In step420, financial service provider system130begins verification of the identification data. Step420may include preliminary checks, such as verification that all data sent by card issuing system110was received by financial service provider system130and whether any data is missing or corrupted. In the event of corrupted or missing data, financial service provider system130may request card issuing system110to retransmit the data. If data is successfully verified it may proceed to further, more advanced verification steps.

Process400then proceeds to step430, where financial service provider system130determines if customer data is available in internal database125. The determination process may determine whether all or portion of the data related to the customer is available. Final decision regarding availability may be determined based on a preset parameter for key data points. For example if the name of the customer is known but no other information is available, the system will treat determination process as failed and will process as if customer data is not available.

In the event the financial service provider system130determines that there is insufficient customer data in the internal database125, process400proceeds to step432. In step432financial service provider system130sends a request for additional data to third party verification system120. Additional data identified in the request may include a combination of data known and not known to the system. Decision on which data to request may be made based on multiple factors, such as confidence in the accuracy of the data, age of the known data, importance of the data, etc. Multiple requests may be made to different third party verification systems. For example, a request regarding driver license information may be made to a local DMV, and a request for credit history may be made to a credit reporting agency. Requested data may further include biometrics data.

After a request is made, process400proceeds to steps434and436, where financial service provider system130receives and stores requested information from third party verification system120. Received information may be compared to the information received from card issuing system110and to the information already stored in internal database125. Duplicate information may be treated based on the preset priority parameters, e.g. information received from government sources always overrides existing information, or information received form partner financial systems may be judged based on age of the information, with newer information getting a priority.

After received information is stored or in the event the financial service provider system130determined that there is already sufficient amount of data available in the internal database125process400proceeds to step440. In step440, financial service provider system130determines if all information in the internal database, which may include newly collected data, is sufficient to make a verification decision. Determination may be made based on the preset parameters. In one embodiment, a component confidence parameter may be utilized wherein each component of collected data is assigned a confidence value and if total confidence value reaches certain threshold then verification is deemed successful.

In the event financial service provider system130determines that there is not enough data collected to make a verification determination, process400proceeds to step442. In step442, financial service provider system130sends a request to collect biometric data to card issuing system110. Collection of biometric data by card issuing system110is described earlier in reference to process300ofFIG. 3. Types of biometric data that may be requested are previously described.

After a request is made, process400proceeds to steps444and446, where financial service provider system130receives and stores requested information from card issuing system110. New data is stored in internal database125and may be used in the future.

After received information is stored or in the event the financial service provider system130determined that there is already enough data available in the internal database125process400proceeds to step450. In step450, financial service provider system130determines if customer data together with biometric data are sufficient to verify customer identity. This determination may be made based on the preset parameters. In one embodiment, a component confidence parameter may be utilized wherein each component of collected data is assigned a confidence value and if a total confidence value reaches certain threshold, then data is deemed sufficient.

In the event the financial service provider system130determines that there is not enough data to verify customer identity, process400proceeds to step452. In step452, financial service provider system130send instructions to a customer to contact a fraud department. Instructions may be sent via a contact method on file, e.g. email, text, telephone, etc. Process400then proceeds to step452, where financial service provider system130sends a “Verification Failed” message to card issuing system110. The “Verification Failed” message may include a specific reason why the verification failed.

Alternatively, in the event the financial service provider system130determines that there is enough data to verify customer identity, process400proceeds to step460. In step460, financial service provider system130sends a “Verification Passed” message to card issuing system110.

FIG. 5is a flow chart of a process500for customization of the transaction card. Process500starts at step510where card issuing system110receives a customer request for customization of a card. The request may include a selection of a template or custom uploaded image, and may be made during issuance of a new or replacement card, as previously described.

Process500then proceeds to step520, where card issuing system110send directions to the customer to stand in a designated area to capture an image to be embossed on the custom transaction card. Directions may include arrows, a schematic outline of the designated area, voiced guidance, etc. Directions may change based on unsuccessful attempts to stand in the designated area.

Process500then proceeds to step530, where card issuing system110captures an image of the customer and displays the captured image to the customer in the following step540. While the image is displayed to the customer, customer may make edits to the captured image. Edits may include resizing the captured image, cropping the captured image, rotating an image, etc. The customer may then send an approval of the captured image or recapture an image. If approval is received by card issuing system110, process500continues to step560, where the customer is issued a new customized transaction card. The captured image may further be saved and used for biometrics verification.

Furthermore, although aspects of the disclosed embodiments are described as being associated with data stored in memory and other tangible computer-readable storage mediums, one skilled in the art will appreciate that these aspects can also be stored on and executed from many types of tangible computer-readable media, such as secondary storage devices, like hard disks, floppy disks, or CD-ROM, or other forms of RAM or ROM. Accordingly, the disclosed embodiments are not limited to the above described examples, but instead are defined by the appended claims in light of their full scope of equivalents.

The foregoing description is presented for purposes of illustration. It is not exhaustive and is not limited to the precise forms or embodiments disclosed. Modifications and adaptations of the embodiments will be apparent from consideration of the specification and practice of the disclosed embodiments.

Computer programs based on the written description and methods of this specification are within the skill of a software developer. The various programs or program modules can be created using a variety of programming techniques. One or more of such software sections or modules can be integrated into a computer system, non-transitory computer readable media, or existing software.