in order to increase the level of security on debit products while providing value - add features , the present disclosure provides a novel form of personal authentication at the service level to increase card holder and card issuer trust during card not present ( cnp ) transactions . referring now to fig1 , illustrated is a functional schematic diagram depicting a customer interaction , generally 100 , for cnp verification according to an embodiment of the present disclosure . in the interaction 100 , the cardholder 102 engaged in a communication with an electronically hosted platform 104 . generally , this communication will entail internet web - based communication from the cardholder &# 39 ; s 102 home or office , but may also include interaction with a remote kiosk ( not shown ) that is in communication with the platform 104 . the cardholder 102 is first presented with a generic welcome or home page 106 , i . e ., one which is presented to all visitors or entrants of the platform 104 . from the home page 106 , the cardholder 102 makes a selection that they wish to engage in an interaction related to their payment card ( e . g ., purchase transaction , obtain services related to their card account , etc .). in response to this indication from the cardholder 102 , the platform 104 presents the cardholder with a validation page 108 . at the validation page 108 , the cardholder 102 is requested to provide the relevant information from and relating to their payment card , including without limitation : the account number associated with the card ( aka , the primary account number or pan ); the expiration date of the card ; a card validation code ( cvc ) string , which is typically , but need not exclusively be , a numeric string ; billing address or billing zip code of the associated account ; etc . this payment card - related information is passed by the platform 104 to a data engine 110 . the data engine 110 may be considered part of a back - end — i . e ., not directly visible to the cardholder 102 — of the platform 104 , for example where the platform is hosted by the card payment services network operator . alternately , the data engine 110 may represent a service provided to an operator of the platform 104 , for example where the platform is an e - commerce site operated by a merchant accepting the payment card for transactions , the data engine 110 is serviced by the card payment services network operator . the data engine 110 carries out the necessary interactions to verify the identity of the cardholder as described further herein . the deliverable from the data engine 110 to the platform 104 are two - fold . first , the data engine 110 is to , by one or more of the techniques described herein , or others as may be or come to be known , confirm the validity of the pan and associated information as provided by the cardholder 102 , and further to provide information derived from the account associated with the pan given , as part of a challenge - response verification of the cardholder 102 identity . the data engine 110 may obtain the necessary information in one of a number of ways , as described hereinafter . having obtained the deliverable information , the case where the pan or any associated card information is invalid 112 can result in an error message returned to the cardholder 102 via the validation page 108 . if information was inadvertently mistyped , etc ., the cardholder 102 may try again to enter the correct information . certain limitations on a permissible number of failed attempts , in a given time frame , from a given ip address , etc ., or some combination of these and / or other security features , may be employed . alternately or additionally , e . g ., after exceeding permissible number of failed attempts based , the validation may be terminated at 124 . in some cases , the termination may be opaque to the cardholder 102 as to the precise reason for the termination . on the other hand , where the data engine 110 receives confirmation of the validity 114 of the pan , the data engine 110 will also have requested and received from the issuing institution a sample of transactional data associated with the underlying account . such transaction data may include , without limitation , the date , time and / or merchant involved with some predetermined number of transactions . other transaction data may include a day and amount of last payment or deposit on the account , or the account balance on a given date . the data engine 110 passes the pan validity confirmation 114 along with the transactional data to the platform 104 . the platform 104 then uses the transactional data as the basis for a challenge / response test 116 , presented to the cardholder 102 in order to verify the cardholder &# 39 ; s identity . the challenge / response test 116 may use the transactional data in a variety of ways . the cardholder 102 can be asked to verify , either in an open - ended or multiple choice manner , information pertaining to a recent transaction , including without limitation the date , amount , or merchant involved . for example , presuming the transactional data indicated a purchase from abc specialty store on mar . 12 , 2012 in the amount of $ 27 . 50 . a sample question might read : on mar . 12 , 2012 , you made a purchase using your mastercard debit card in the amount of $ 27 . 50 . what is the name of the merchant involved in this transaction ? a ) jane &# 39 ; s clothing boutique b ) abc specialty store c ) xyz supermarket d ) i do not recognize this transaction . as here , the offered responses may include a default response ( response d , in this case ) in order to hold open the possibility that the question is a red herring , i . e ., that no such transaction exists . alternately , the challenge question may inquire about the amount of the purchase while giving the merchant and date ( or a fictitious pretext of a transaction to which a response such as d , above , would be appropriate ). the challenge question may inquire about the date and time of the most recent payment or deposit to the linked account , or the amount of such payment or deposit . where the subject of the challenge question is a dollar amount , or some other numeric value ( e . g ., date ), the cardholder 102 may be presented with answers in the form of a range or band of values , one of which may include the correct value . it will generally be at the discretion of the operator of platform 104 , in consultation with the operator of the data engine 110 , to determine the level of correct responses required to authenticate the cardholder 102 . for example , this will include the number of challenge questions to be answered correctly , a permissible number of incorrect answers , etc . where the challenge questions present a limited number of possible responses , as in the example above , it is possible that the appropriate answer to any challenge question can be selected by mere chance . therefore , there is an advantage in terms of the strength and reliability of the authentication to require a minimum number of challenge questions be answered correctly in order to be authenticated . generally speaking , the probability that a series of challenge questions with a finite number of possible responses , if answered randomly , will result in all appropriate responses is equal to one chance in x raised to the power of y , where x is the number of possible answers to each question presented , and y is the minimum number of correct answers . for example , if there are four possible answers to each challenge question and a minimum of four questions must be answered correctly to authenticate the cardholder 102 , then there is a one in 256 ( 4 4 ) chance of guessing all four questions correctly , 0 . 39 %. allowance for at least one incorrect answer , i . e . requiring only 3 correct answers , would increase the probability that a series of random guesses will result in an authentication to 1 . 6 %, or one in 64 ( 4 3 ). however , considering that a sufficient number of correct answers must be received before a threshold number of incorrect answers ( for the sake of this example , one ) is exceeded , the amount by which that probability increases is further limited . it is generally considered that there will be one of three outcomes of the challenge / response question 116 . in a first instance , the response to challenge questions will meet the required threshold for successful validation 118 . the cardholder 102 may provide a response to a challenge question 120 , where additional questions are needed to complete the validation . it may be that the response was correct , but more correct responses are necessary to achieve a minimum threshold for verification . alternately , the response may be incorrect , but within a tolerance ( if any ) of permissible incorrect answers . alternately , the cardholder 102 may provide an response to a challenge question , and have also exceeded a tolerance of permissible incorrect answers , if any was established , such that the validation is unsuccessful 122 . taking these cases retrospectively , if one or more unsuccessful responses to a challenge question indicate beyond a threshold level that the user interacting with the platform 104 cannot be validated as the authentic cardholder 102 , then the process is terminated 124 , in some instances discretely and / or opaquely to the user interacting with the platform 104 . the user may be returned to the home page 106 . the platform 104 may or may not afford the same user another opportunity to validate themselves with the same or alternate credentials . on the other hand , it may be the case that a response , correct or incorrect , requires and permits additional questions 120 to complete the validation . the user may or may not be apprised that their response was insufficient . from the user point - of - view , it should preferably be opaque as to whether their response was adequate to the challenge . moreover , from a standpoint of data security , only the minimum necessary transactional information may be released to the operator of the platform 104 . it may be the case that an initial data provisioning 114 includes sufficient information to frame a minimum adequate number of challenge / response questions . thus , if one question is answered incorrectly , it may not be immediately necessary to seek additional transactional data from the data engine 110 , as illustrated in fig1 via the broken line path from 120 to 116 , including data engine 110 . if the user is within an established tolerance of incorrect answers , then another challenge question may be presented 116 . if one or more questions are answered incorrectly , and only a minimum provision of data was supplied , additional information would be needed before completing the validation . in that case , the platform 104 would revert to the data engine 110 from the state of 120 , for additional data . thereafter , the cardholder 102 would be presented with additional challenge / response questions 116 , leading to either a successful validation 118 , or a rejection of validation 122 . alternately the data may be held securely by the data engine 110 . the data engine 110 would supply the challenge questions and a range of answers to the platform 104 . the platform 104 in that scenario would pass the responses supplied by the cardholder 102 to the data engine for validation . alternately an initial data provision 114 from the data engine 110 might include sufficient information to frame a number of challenge / response questions including allowance for incorrect responses . additional security measures , for example a prohibition against data storage by the platform 104 following the validation result , and / or direct management of the challenge / response process by operator of the data engine 110 , may also be provided . finally , upon successful completion of a specified number of challenge / response questions 118 , the cardholder 102 is presented with a page that permits them to consummate the interaction 126 for which they began the validation . this may be a purchase transaction , obtaining access to a card - related product or service , reporting a lost or stolen payment card , without limitation . following the successful consummation of the interaction 126 , the cardholder is present with a confirmation of their successful completion 128 . we turn now to the acquisition by the data engine 110 of the transaction data to be provisioned to the platform 104 . referring to fig2 a and 2b , illustrated are first and second methods , respectively , for the data engine 110 to obtain the necessary information . there are essentially two parallel systems for processing purchase card ( i . e ., credit or debit ) transactions . the first , represented in fig2 a , is the banknet authorization system . by way of background , the banknet system is characterized by its use of two sequential messages in order to consummate any given transaction . the first message is an authorization message , which seeks an authorization to complete a given transaction from the institution holding the account on which the card is issued . the response to the authorization is passed on to the merchant , for example . a second message is sent to ‘ clear ’ the transaction once the merchant has provided the goods or services bargained for , and initiates the transfer of funds according to the previous authorization . on the other hand , and with reference to fig2 b , card transactions may be processed through a parallel and competing payment network known as merchant data service ( mds ). the mds network is characterized in that transactions are processed in a single transaction message and response ( e . g ., approve or decline ), rather than two messages as described above with reference to the banknet system depicted in fig2 a . in both use cases , fig2 a and 2b , the message protocol may be configured to allow the message from data engine 110 to be of an inquiry nature , rather than a message seeking to initiate a transaction on the account . moreover , the communication protocol further provides for data to be requested , for example as part of the authorization inquiry , with the response message from the issuer including the requested payload data . in those circumstances , the message transmitted to the issuing bank , i . e ., the entity responsible for issuing the payment card and which also holds the credit or demand deposit account on which the payment card draws , via either the banknet or mds systems , as applicable to the particular issuer . the inquiry message 202 a , 202 b , from the data engine 110 will be of an inquiry nature only , i . e ., not of a type initiating a transaction . the inquiry message 202 a , 202 b is routed through the mastercard interface processor ( mip ) e . g ., 220 a , 220 b , where the payment card is a mastercard brand — the process being analogous or equivalent for other brands of credit card as well . the inquiry message 202 a , 202 b from the data engine 110 is routed by the issuer card management system , e . g ., 220 a , 220 b . the inquiry message 202 a , 202 b will include a request from the data storage 204 a or 204 b for recent transaction data on the account , e . g ., of the most recent transactions ( choosing five , for the sake of illustration , more or less being within the scope of the present disclosure ), the transaction date , the transaction type ( purchase , return , deposit , payment , etc . ), the merchant entity , if applicable . the response from to the data engine 110 inquiry message the issuer will preferably include the requested payload transactional data . this transactional data is then passed to the platform 104 by the data engine 110 to formulate the challenge / response questions as described above . the foregoing discussion of fig2 a , 2 b presumes that the particular issuer is configured to receive and respond to such requests for transactional information in the transaction data stream . because the transaction processing system is backwards compatible , not all issuers are rigorously current with the most recent protocols and capabilities , including inquiries for payload data as described . in that case , other means of obtaining the verification information are contemplated . to that end , we turn to fig2 c . fig2 c , illustrates is still another embodiment for obtaining the requisite transaction data for verifying cardholder 102 identity . in this case , the financial institution is not operating under protocols outlined in either fig2 a or 2 b above , but does allow atm interaction with the account , for example to permit balance inquiries or cash withdrawals . many such institutions are configured to provide so - called mini - statements upon request . a mini - statement includes an account balance , and a précis of transaction detail for some predetermined range of transactions on the account , e . g ., previous five transactions , or up to 7 transactions in the last 90 days , or the like . transactions may include charges , refunds , credits , deposits , withdrawals , payments , etc . therefore , the data engine 110 is optionally enabled to issue a request 206 for a mini - statement to the financial institution . that request 206 is likewise routed through a mip 220 c , and likewise handled by the issuer &# 39 ; s card management system 222 c . the data requested , drawn from the data storage 204 c , is included in the responsive mini - statement . that mini - statement data then forms the basis of the challenge and response questions presented to the cardholder 102 . the financial institution holding a given account is the preferred source for transactional data , in part because it will have the most up - to - date information concerning the account , and may have information not available to the network operator or a third - party intermediary ( payment or deposit data on a credit or debit account , respectively , for example ). one advantage this provides is for additional types of data , and further that most recent transactions will be fresh in the mind of the cardholder 102 , giving the cardholder 102 the best opportunity to avoid an incorrect answer that might result in a false - negative denial of access , simply because they do not remember the transaction embodied a given question . however , in the case that the requisite transaction data is not available from the issuer on the corresponding account , the network operator may look to other resources . illustrated in fig2 d , 2 e are a fourth and fifth method , respectively , to obtain the transaction data to perform the validation sought herein . in consideration of fig2 d , 2 e , it may be the case that the financial institution holding the demand deposit account or line of credit account that funds the particular pan is for any number of reasons , whether intermittent or continuing , unable to provide the necessary information to compose verification challenge and response questions . in its capacity as operator of a cashless transaction facilitation network , the network operator ( which the instant assignee is one ) has access to transaction data related to card - based transactions . a network operator may maintain a data warehouse including a historical record of such transactions . therefore , where the financial institution maintaining the account underlying the transaction is not the source of the necessary data , with reference to fig2 d , the network operator may look to its own data warehouse for a selection of transactions associated with the pan involved in the present verification . in other respects , the process proceeds as if the issuing financial institution were providing the data . the query 208 of the data warehouse 210 will verify the validity of the pan , as well as provide the necessary transactional data to perform the cardholder 102 validation . turning then to fig2 e , illustrated is the case where the network operator itself does not intermediate transactions , for example in certain international jurisdictions under local law . in any event , there is a third - party intermediary , who likewise maintains a data warehouse of transaction data . therefore , the use case of fig2 e is largely analogous to that of fig2 d , except that it involves a query 212 issue to a third - party source of stored transaction data 214 . in any of the foregoing embodiments , it will be to the advantage of the network operator to maintain a reference or table of which financial institutions are responsive to which of the foregoing methods , if any , of obtaining the required transaction data . the financial institution will be identifiable from the bank identification number ( bin ), which forms a part of the pan for each card account . the data engine would be enabled , by consultation with the reference or table , issue the appropriate request , whether to the financial institution as according to fig2 a , 2 b or 2 c ; to an internal data warehouse as according to fig2 d , or to a third party as according to fig2 e . it is also contemplated that the methods disclosed herein are not mutually exclusive of one another , and may be used in combination . for example , if an inquiry to the issuing financial institution fails due to a communication breakdown between the data engine 110 and the issuer , then the network operator may revert to other sources of data , e . g ., those described with respect to fig2 d and / or 2 e . it will be appreciated by those skilled in the art that the methods as described above may be operated by a machine operator having a suitable interface mechanism , and / or more typically in an automated manner , for example by operation of a network - enabled computer system including a processor executing a system of instructions stored on a machine - readable medium , ram , hard disk drive , or the like . the instructions will cause the processor to operate in accordance with the present disclosure . turning then to fig3 , illustrated schematically is a representative computer 616 of the system 600 . the computer 616 includes at least a processor or cpu 622 which is operative to act on a program of instructions stored on a computer - readable medium 624 . execution of the program of instruction causes the processor 622 to carry out , for example , the methods described above according to the various embodiments . it may further or alternately be the case that the processor 622 comprises application - specific circuitry including the operative capability to execute the prescribed operations integrated therein . the computer 616 will in many cases includes a network interface 626 for communication with an external network 612 . optionally or additionally , a data entry device 628 ( e . g ., keyboard , mouse , trackball , pointer , etc .) facilitates human interaction with the server , as does an optional display 630 . in other embodiments , the display 630 and data entry device 628 are integrated , for example a touch - screen display having a gui . variants of the above - disclosed and other features and functions , or alternatives thereof , may be desirably combined into many other different systems or applications . various presently unforeseen or unanticipated alternatives , modifications , variations , or improvements therein may be subsequently made by those skilled in the art which are also intended to be encompassed by the following claims .