US20080021803A1 - Systems and methods for selectively delaying financial transactions - Google Patents

Systems and methods for selectively delaying financial transactions Download PDF

Info

Publication number
US20080021803A1
US20080021803A1 US11/832,505 US83250507A US2008021803A1 US 20080021803 A1 US20080021803 A1 US 20080021803A1 US 83250507 A US83250507 A US 83250507A US 2008021803 A1 US2008021803 A1 US 2008021803A1
Authority
US
United States
Prior art keywords
merchant
risk
customer
financial transaction
check
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US11/832,505
Inventor
Daniel Ahles
Randy Templeton
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
First Data Corp
Original Assignee
First Data Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by First Data Corp filed Critical First Data Corp
Priority to US11/832,505 priority Critical patent/US20080021803A1/en
Publication of US20080021803A1 publication Critical patent/US20080021803A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • G06Q20/042Payment circuits characterized in that the payment protocol involves at least one cheque
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/03Credit; Loans; Processing thereof
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange

Definitions

  • the present invention relates to financial transactions and, in particular, to a system and method of risk assessment, whereby provisional authorization may be granted to a merchant for the selective delay of a financial transaction.
  • a typical financial transaction involves a form of payment in exchange for vendibles, such as services and/or merchandise, at a point of sale.
  • a customer provides the form of payment, such as a promissory check draft, to a merchant in exchange for the vendibles.
  • the check draft is often regarded as a promissory payment that instructs the customer's bank to pay the merchant.
  • the funds promised to the merchant by the check draft are sometimes not paid due to reasons, such as insufficient funds in the customer's checking account or fraud.
  • the merchant may be susceptible to risk whenever a check draft is received as payment for services and/or merchandise.
  • the merchant may choose to manage risk by maintaining one or more local databases that may include, for example, a list of customers or check writers that have written bad checks in the past.
  • databases may range from a simple list on paper for a small store owner to a computer network for a chain store.
  • managing such databases requires use of merchant resources that could otherwise be used more beneficially.
  • the merchant may choose to manage risk by subscribing to an agency that assess the risk associated with promissory check related financial transactions.
  • a risk assessment agency include TeleCheck.
  • a subscribed merchant sends a transaction approval request to the agency with information, such as promissory check draft amount, check identifying information, and information about the check writer.
  • the agency assesses the risk and generates a risk score based on the information received.
  • the agency then either approves or declines the transaction based on the generated risk score.
  • the level of subscription to such an agency may vary, from an approval service to the agency assuming the risk of the transaction by either guaranteeing the check or purchasing the check from the merchant. Thus, it is in the interest of the agency to accurately assess the risks associated with financial transactions.
  • a conventional check approving process may comprise a cutoff risk score such that a transaction whose risk score is higher than the cutoff risk score is approved. Conversely, a transaction whose risk score is lower than the cutoff risk score is declined.
  • a borderline risk score is positioned somewhere between the low risk score and the high risk score, which is somewhat near the cutoff risk score. Consequently, since the above-mentioned check approval process is generally configured to statistically favor the merchant or the check approving agency in terms of probable risk, borderline risk assessments are often declined in many check transactions that correspond to borderline risk scores.
  • the merchant and/or the check approving agency typically declines the financial transaction and the customer is required to present another form of payment or abandon the requested financial transaction altogether.
  • marginal risk situations result in lost revenue for the merchant due to the occurrence of borderline or marginal risk assessment declines.
  • the present invention provides a method and system which selectively delays the financial transaction until further transaction information may be obtained and processed for review and evaluation in borderline or marginal risk assessment situations.
  • a method of assessing risk associated with a financial transaction is described herein below, wherein a customer is attempting to pay for vendibles from a merchant via a promissory payment.
  • the method comprises, first, receiving transaction information from the merchant at a point of sale, wherein the transaction information identifies the customer, the merchant, and includes data about the financial transaction.
  • the method further comprises assessing the risk of the financial transaction using at least one mathematically based scoring engine to obtain a risk value.
  • the method further comprises determining if the risk value indicates that the risk is in a first classification of risk wherein additional information about the customer may result in the risk value being positioned within a second classification of risk for which acceptance of the promissory payment as payment for the vendibles is warranted.
  • the method comprises provisionally authorizing acceptance of the promissory check if the risk value determination indicates that the risk value is in the first classification, and communicating the provisional authorization to the merchant at the point of sale to thereby indicate to the merchant to accept the tendered promissory payment but to hold delivery of the vendibles for a pre-selected period of time.
  • the method comprises obtaining additional financial data about the customer during the pre-selected period of time to determine if the risk value can be positioned within the second classification, and authorizing delivery of the vendibles after the pre-selected period of time when the additional financial data about the customer indicates that the risk value can be positioned in the second classification.
  • the method may further comprise determining if the merchant is a merchant who can delay delivery of the vendibles and wherein communicating the provisional authorization to the merchant occurs only if the merchant is determined to be a merchant who can delay delivery of the vendibles.
  • assessing risk associated with the financial transaction may correspond to assessing risk associated with an internet based financial transaction and/or a mail order based financial transaction.
  • authorizing delivery after the pre-selected period of time may comprise contacting the merchant and advising the merchant to deliver the vendibles and wherein authorizing delivery after the pre-selected period of time comprises agreeing with the merchant that unless the merchant is advised to not ship at the end of the pre-selected period of time, the delivery of the vendibles is authorized.
  • the pre-selected period of time may range from at least one micro-second to a few weeks.
  • obtaining additional financial information about the customer may comprise verifying availability of funds in a checking account belonging to the customer to cover the cost of the financial transaction.
  • obtaining additional financial information about the customer may further comprise obtaining information about the customer's recent check writing history and evaluating the customer's recent check writing history to predict whether there will be sufficient funds to cover the cost of the financial transaction.
  • attempting to pay via the promissory payment may comprise attempting to pay via a check, an electronic check, and/or a paper check, and wherein attempting to pay for vendibles may comprises attempting to pay for services and/or merchandise.
  • a system of assessing risk associated with a financial transaction wherein a customer is attempting to pay for vendibles from a merchant via a promissory payment.
  • the system comprises a risk assessment component that is configured to perform a risk assessment of the financial transaction using at least one scoring engine to generate a risk score based on transaction information obtained from the merchant via an interface component, wherein the transaction information identifies the customer, the merchant, and includes data about the financial transaction.
  • system further comprises a processing component that is configured to determine a marginal risk assessment if the risk score is in a borderline classification of risk, wherein additional customer information may result in the risk score being positioned within a low classification of risk for which acceptance of the promissory payment for the vendibles is authorized.
  • system further comprises a communications component that is configured to communicate with the merchant, wherein the communication component notifies the merchant at the point of sale, and wherein the notification instructs the merchant to accept the tendered promissory payment but to delay delivery of the vendibles for a period of time, wherein, during the period of time, additional financial data about the customer is obtained via the interface device to re-assess the risk associated with the financial transaction.
  • a communications component that is configured to communicate with the merchant, wherein the communication component notifies the merchant at the point of sale, and wherein the notification instructs the merchant to accept the tendered promissory payment but to delay delivery of the vendibles for a period of time, wherein, during the period of time, additional financial data about the customer is obtained via the interface device to re-assess the risk associated with the financial transaction.
  • the system may comprise an authorization component that is configured to authorize delivery of the vendibles after the period of time when the additional financial data about the customer indicates that the risk score can be re-positioned in the low classification of risk.
  • the authorization component may further comprise a communications device and contacts the merchant via communications medium and advises the merchant to deliver the vendibles to the customer.
  • the authorization component may be used to authorize the delivery of the vendibles after the period of time unless the merchant is advised to not ship at the end of the period of time by the authorization component.
  • the period of time ranges from at least one micro-second to a few weeks.
  • the processing component is further configured to determine if the merchant is a merchant who can delay delivery of the vendibles, wherein the processing component determines the marginal risk assessment only if the merchant is determined to be a merchant who can delay delivery of the vendibles.
  • the financial transaction is an internet based financial transaction and/or a mail order based financial transaction.
  • system is may be configured to acquire additional customer information and verify the availability of funds in a checking account belonging to the customer to cover the cost of the financial transaction, wherein the additional customer information comprises transaction information about the customer's recent check writing history.
  • processing component may also be configured to evaluate the customer's recent check writing history to predict whether there will be sufficient funds to cover the cost of the financial transaction.
  • FIG. 1 illustrates one embodiment of a financial transaction involving a check draft and a check acceptance service.
  • FIG. 2 illustrates one embodiment of a schematic block diagram of the check acceptance service in FIG. 1 including a risk system and a Model/Action/Rules processor.
  • FIG. 3 illustrates one embodiment of a check approval process flow that describes the implementation of one aspect of the present invention by the check acceptance service in FIG. 2 .
  • FIG. 4 illustrates one embodiment of a risk assessment process flow that utilizes the risk system, as referenced by FIG. 2 , to selectively re-assess the transaction variables, parameters, and information relevant to the financial transaction.
  • FIG. 5 illustrates one embodiment of a check approval process performed by the Model/Action/Rules processor as referenced by the risk system in FIG. 2 .
  • FIG. 1 illustrates one embodiment of a financial transaction involving a promissory check draft.
  • a customer 100 provides the check draft 102 to a merchant 106 or service entity in exchange for vendibles 104 , such as a service or merchandise.
  • the check draft 102 may be accepted and deposited into a merchant bank 112 without receiving any external authorization as indicated by path 120 .
  • the check draft 102 is electronically transferred through a clearing process, wherein the merchant bank 112 transfers the check draft 102 to a federal clearing house (FCH) 114 as indicated by path 122 .
  • the federal clearing house 114 transfers the check draft 102 to the check issuing bank 116 as indicated by path 124 .
  • the check draft 102 is determined to be valid by the check issuing bank 116 , then the check “clears” and the amount of the check 102 is debited from the customer's 100 checking account in the check issuing bank 116 , and the debited amount is subsequently transferred to the merchant's 104 account in the merchant bank 112 as indicated by path 126 .
  • the check draft 102 may not clear for various reasons. As a result, the merchant's 106 bank account is not credited with the check amount. For example, the check issuing bank 116 may provide a non-sufficient fund (NSF) statement corresponding to the customer's 102 checking account, a stop payment request by the customer 100 , and/or a fraudulent check issuance.
  • NSF non-sufficient fund
  • the check draft 102 fails to clear, the merchant 106 is left with the responsibility of collecting the proper funds or the vendibles 104 from the customer 100 . In some instances, the merchant 106 may be unsuccessful in reclaiming the proper funds in a collection process, and the already released merchandise may be written off as a loss.
  • the collection process significantly increases the merchant's 106 costs associated with the financial transaction.
  • the customer's 102 name may be added to a negative list, such as an internal or local database.
  • the local database may offer only limited protection against “bad” check writers, who may have previously bounced checks in the merchant's 106 establishment.
  • “bad” check writers who may not have previously bounced checks in the merchant's 106 establishment, but have a history of bouncing checks or writing fraudulent checks elsewhere, are unlikely to be detected by such a local database.
  • the subscription service may comprise the process of the check acceptance service 110 informing the merchant 106 to accept or refuse the check 102 based on the risk associated with the particular financial transaction. If the check draft 102 is approved and accepted, the check draft 102 is then transferred through the clearing process via the merchant bank 112 in a manner similar to that described above. Unfortunately, if the clearing process is not completed successfully, the merchant 106 usually assumes the risk associated with the financial transaction.
  • Another embodiment of the subscription service may comprise the process of the check acceptance service 110 guaranteeing the validity of the check 102 based on the risk associated with the particular financial transaction.
  • the check draft 102 is transferred through the clearing process via the merchant bank 112 in a manner similar to the previous description. Fortunately for the merchant 106 , if the check 102 fails to clear, the check acceptance service 110 credits the merchant 106 for the amount of the check draft 102 and assumes the responsibility of collecting the funds from the customer 100 .
  • Still another embodiment of the subscription service may comprise the process of the check acceptance service 110 purchasing the check draft 102 outright from the merchant 106 based on the risk associated with the financial transaction.
  • the merchant 106 receives payment for the financial transaction upon approval or authorization from the check acceptance service 110 .
  • the check acceptance service 110 may be electronically linked to the merchant bank 112 , as indicated by path 136 , to electronically transfer the necessary funds.
  • the check acceptance service 110 assumes the responsibility of clearing the check draft 102 .
  • the check draft 102 may be transferred from the check acceptance service 110 to the federal clearing house (FCH) 114 as indicated by path 132 .
  • the check draft 102 may be transferred to the check issuing bank 116 as indicated by the path 124 .
  • the necessary funds are transferred from the check issuing bank 116 to the check acceptance service 110 as indicated by path 134 .
  • the financial transaction is regarded as complete for the check acceptance service 110 .
  • the check acceptance service 110 assumes the responsibility of collecting the necessary funds from the customer 100 .
  • Various subscription services comprise diverse fee schedules that are significantly determined by the risks associated with the encountered financial transactions. It should be appreciated that the success of the check acceptance service 110 , including profitability, may substantially depend on accurate risk assessments that may be associated with check related financial transactions. For example, if the check acceptance service 110 provides misguided or erroneous approval decisions to the merchant 106 , then the merchant 106 accepts high risk check drafts and/or refuses beneficial customers, which may result in lost revenue or dissatisfied customers. In other situations, the risk is assumed by the check acceptance service 106 , and profitability is directly related to the accuracy of risk assessments.
  • the technology associated with financial transactions and the electronic transfer of funds by a central financial transaction entity or the check acceptance service 110 include monetary exchange devices, such as check readers, credit card readers, debit card readers, manual input of account information, or some combination thereof for the purpose of obtaining authorization for and settlement of financial transactions at the point of sale.
  • financial transfer systems may include a point of sale terminal, which may include a display monitor, a printer, magnetic card reader, and a magnetic check reader.
  • the check draft 102 or a credit card may be presented by the customer 100 to the merchant 106 and swiped through the check reader or magnetic card reader, respectively.
  • the check reader portion of the point of sale terminal identifies, by either magnetic ink character recognition (MICR) or optical character recognition (OCR), the American Banking Association (ABA) account information printed on the face of the check draft 102 or stored in the magnetic strip of the credit card, respectively, and converts the customer's ABA account information to transactional data, which may include digital signals or digital signatures pertaining to the financial transaction.
  • MICR magnetic ink character recognition
  • OCR optical character recognition
  • ABA American Banking Association
  • Transactional data may also include customer 100 identification information, wherein the customer 100 may be required to provide identification, such as a driver's license, or the customer 100 may then be prompted to enter a personal identification number (PIN) associated with corresponding account.
  • PIN personal identification number
  • the merchant 106 may then enter the pertinent sale data that indicates the amount of the transaction to be authorized, wherein this information may also be converted into transactional data.
  • the resulting collective transactional data is then transferred to the check acceptance service 110 for additional authorizational processing and evaluation.
  • additional authorizational processing and evaluation may include verifying the existence of finds in the customer's check issuing bank account in a manner as described in FIG. 1 .
  • obtaining additional financial information about the customer may also comprise obtaining information about the customer's recent check writing history and evaluating the customer's recent check writing history to predict whether there will be sufficient funds to cover the cost of the financial transaction.
  • the customer's check writing history may be logged in an internal database, an external database, and/or saved as a merchant parameter in a memory component.
  • transaction information including merchant information and customer information, relating to approved and/or declined financial transactions is recorded in a data warehouse of the central financial transaction entity or the check acceptance service 110 for the merchant's 106 future reference, wherein the check acceptance service 110 may generally update transactional information on a daily basis in a batch process, and daily reports may be generated to provide both detailed and summary records of transaction information.
  • the check acceptance service 110 may begin authorizational processing by verifying the transactional data with authorization algorithms that may use an ABA account number-PIN pair database and a review of funds verification.
  • the ABA account number-PIN pair database or some other internal database maintains a file of ABA account information and the personal identification numbers corresponding to respective accounts.
  • the review of funds verification is a system adapted to bi-directionally communicate with a financial institution, such as the check issuing bank 116 to determine that sufficient funds exist in the customer's account for the desired financial transaction.
  • the check acceptance service 110 may provide provisional authorization 140 , in marginal risk assessment situations, to the merchant for the financial transaction.
  • provisional authorization 140 allows the check acceptance service 110 to selectively re-evaluate the customer's transaction information prior to an approval or decline.
  • provisional authorization 140 allows the merchant to delay delivery of the vendibles 104 until further risk assessment and/or analysis is processed by the central financial transaction entity or the check acceptance service 110 .
  • the check acceptance service 110 may provide the merchant 106 a response indicating provisional authorization 140 . In some cases, the merchant 106 avoids issuing marginal risk declines, which results in customer satisfaction and increased sales.
  • the check acceptance service 110 records the MICR information and generates a transactional identification number. If the personal identification number is determined to correspond to the account number and sufficient funds are available in the account, an approval number is assigned to the financial transaction. Additionally, the check acceptance service 110 generates electronic debit and credit files for submission to an automated federal clearing house (FCH) 114 or federal reserve network computer. These electronic files instruct the customer's bank 116 or the paying financial institution to deposit the necessary funds in the merchant's bank 112 or the depositing financial institution. The FCH 114 or federal reserve computers execute the debit and credit file instructions, and the paying financial institution accordingly deposits the customer's funds into the depositing financial institution.
  • FCH automated federal clearing house
  • the merchant may issue an instruction to void the financial transaction or to reverse the previous financial transaction instruction in a manner such that the previous instruction credits the merchant's 106 account or credits the customer's 100 account.
  • a significant advantage is achieved with internet and mail order based financial transactions, where a delivery delay of the vendibles 104 is likely to occur in certain situations.
  • a customer 100 may choose to mail a paper check in exchange for ordered vendibles 104 , and therefore the customer 100 expects to wait a period of time for delivery.
  • the check acceptance service 110 may obtain transaction information from the customer 100 and verify the existence of funds electronically prior to receiving the paper check.
  • the check acceptance service 110 may perform various risk assessments, and, depending on the risk assessment, the check acceptance service 110 may notify the merchant 106 to deliver the vendibles 104 or withhold the vendibles 104 until the funds are verified the customer's 100 account. In marginal risk assessment situations, the check acceptance service 110 may provide provisional authorization to the merchant 106 , which informs the merchant 106 to delay the delivery of vendibles 106 until further risk assessment is performed. Without departing from the scope of the present invention, it should be appreciated that, at the time of order, the customer 100 may elect to submit an electronic check to the check acceptance service 110 via the merchant 106 in exchange for vendibles 106 , wherein the check may be processed electronically.
  • the above-mentioned financial transfer system represents a significant improvement over traditional check handling procedures that require the transfer of a paper check among various financial institutions.
  • the above-mentioned financial transfer system includes a mechanism for determining borderline or marginal exception conditions, such as utilizing provisional authorization 140 in borderline or marginal risk situations. If borderline exception conditions or marginal risk assessment situations arise, the above-mentioned financial transfer system suggests the delivery delay of vendibles 104 prior to authorizing the financial transaction in a manner such that the customer 100 is marginally inconvenienced, the merchant retains the merchandise, and the check acceptance service reduces the potential loss of funds.
  • FIG. 2 illustrates one embodiment of a schematic block diagram of the check acceptance service 110 of FIG. 1 .
  • FIG. 2 further illustrates interaction of the check acceptance service 110 with the merchant 106 and the customer 100 in determining the risk associated with a financial transaction.
  • the merchant 106 receives the check draft 102 from the customer 100 , and the merchant 106 electronically interacts with the check acceptance service 110 to determine if the check draft 102 will be accepted or declined.
  • the interaction comprises financial transaction details 142 submitted by the merchant 106 to the check acceptance service 110 , and an approve or decline decision 144 provided by the check acceptance service 110 to the merchant 106 .
  • the financial transaction details 142 and the approve or decline decision 144 are described in greater detail herein below.
  • the check acceptance service 110 comprises a risk system 150 that evaluates the risk involved with a given transaction.
  • the risk system 150 interacts with the merchant 106 via a electronic interface 146 , such as a telephonic, satellite, and/or computer network (internet) interface.
  • the interface 146 receives the financial transaction details 142 from the merchant 106 and passes on the information to the risk system 150 .
  • the risk system 150 may evaluate the financial transaction in a manner described herein below and returns a decision to the interface 146 , which is used to provide the merchant 106 with the desired approve or decline decision 144 .
  • the interface 146 may also access and retrieve relevant information about the customer 100 , such as check writing history, and/or the merchant 106 , such as limit on the check amount acceptable and other specific factors preferences, from an internal database 156 and evaluate the customer and/or merchant parameters so as to permit configuring the manner in which the risk assessment is performed by the risk system 150 .
  • the risk system 150 is also configured so as to permit accessing of an external database 160 , which may comprises a plurality of external databases 174 a , 174 b , etc.
  • the external database 160 permits the risk engine 152 to gather relevant transaction information about the customer 100 and the merchant 106 that may not necessarily be available in the internal database 156 , so as to further facilitate the risk assessment.
  • the risk system 150 further comprises a risk engine 152 that evaluates the risk assessment of the financial transaction based on the financial transaction details 142 or transaction data transferred from the interface 146 , the internal database 156 , and the external database 160 .
  • the risk scoring engine 154 may determine a risk score at the request of the check acceptance service 110 and returns the risk score indicative of a probable risk assessment of the financial transaction.
  • the risk scoring engine 154 may comprise a plurality of scoring engines 172 a , 172 b , 172 c , etc., wherein each risk engine is adapted to address a plurality of possible financial transactions or transaction variables in a manner so as to permit improved accuracy in determining the risk score.
  • scoring engines that may be utilized by the risk engine will be described in greater detail herein below.
  • a preferred financial transaction that illustrates selective use of the plurality of scoring engines will be described in greater detail herein below.
  • the risk engine 152 further comprises a Model/Action/Rules processor 162 that may be utilized to evaluate the transaction risk and may determine whether to approve or decline the financial transaction.
  • the processor 162 comprises a pre-score rules module 164 , a scoring rule matrix module 166 , a post-score rules module, and a delay delivery module 168 .
  • the pre-score rules module 164 is utilized to initially determine whether risk evaluation needs to performed.
  • the risk engine may access the internal database 156 for transaction information about the customer, and ascertains that the customer 100 is associated with a hard negative check writing history.
  • the hard negative check writing history arises from writing one or more non-clearable check drafts and, in some cases, refuses to provide legitimate compensation during the collection process.
  • the pre-score rules module 164 may then decide that the financial transaction is of high risk and, in which case, subsequently declines authorization due to an unacceptable risk assessment ascertained for the customer 100 .
  • the scoring rule matrix module 166 includes a plurality of rules and utilizes the plurality of rules for the purpose of selecting a relevant scoring engine to obtain an initial risk score. Based on the initial risk score, the scoring rule matrix module 166 may approve or decline the financial transaction.
  • the post-score rules module 170 may be utilized to evaluate the initial risk score, that was generated by the scoring matrix 166 , to determine if further risk assessment needs to be performed.
  • the post-score rules module 170 may selectively determine a second scoring engine to run so as to obtain an additional risk score.
  • the additional risk score assessment is performed if the initial risk score leads to a transaction decline according to the scoring rule matrix 166 .
  • the additional risk assessment is performed if the initial risk score falls within a predetermined range of risk score threshold values. It should be appreciated that the additional risk assessment performed selectively may be implemented in any number of situations so as to accurately assess the financial transaction risk.
  • examples and functionality of an exemplary risk assessment may be configured in accordance with methods described in the Applicant's co-pending U.S. patent application entitled “SYSTEMS AND METHODS FOR SELECTIVE USE OF RISK MODELS TO PREDICT FINANCIAL RISK”, Attorney Docket No. 1DATA.045A, which is incorporated herein by reference in its entirety.
  • Some rules invoke other rules based on simple decisions, and some rules invoke scoring engines to determine risk related factors.
  • the rules and the scoring engines illustrated and described in reference to the Applicant's co-pending application are not intended to limit the scope of the risk system.
  • the rules and scoring engines exemplified in the Applicant's co-pending application illustrate one embodiment of the risk assessment associated with the financial transaction described herein below.
  • the delay delivery module 168 may be utilized to provide the merchant 106 with a notification of provisional authorization. In some cases, if the risk engine 152 determines that the financial transaction maintains a borderline or marginal risk exception condition, then the delay delivery module 168 may issue the notification of provisional authorization to the merchant 106 . In one aspect, provisional authorization notifies the merchant 106 that additional risk assessment and evaluation is necessary. The merchant 106 may either delay delivery until the check acceptance service 110 issues a notification of authorization for the financial transaction, or the merchant 106 may elect to deliver the services and/or merchandise after a pre-determined period of time if authorization notification was not issued by the check acceptance service 110 during the pre-determined period of time.
  • the merchant 106 upon receiving the provisional authorization notification, the merchant 106 knows to delay the delivery of services and/or merchandise until further risk analysis may be performed by the risk system 150 .
  • authorizing delivery after the pre-selected period of time may include agreeing with the merchant 106 that unless the merchant 106 is advised to not deliver the service and/or merchandise at the end of the pre-selected period of time, the delivery of the merchandise is authorized.
  • the advantage is that the merchant 106 retains the services or merchandise, the customer 100 is satisfied with the service, and the check acceptance service 110 is given additional time to evaluate further transaction information, including additional risk assessments, prior to approval or decline.
  • the use of provisional authorization inhibits the lost merchandise, dissatisfied customers, and lost revenue for marginal risk assessments.
  • the risk system 150 may request additional information about the financial transaction from the merchant 106 and/or the customer 100 via the interface 146 for further risk assessment, or the risk engine 152 may re-score the risk associated with the financial transaction in the risk scoring engine 154 .
  • the risk system 150 may choose to electronically verify the existence of funds in the customer's 100 account prior to notifying the merchant 106 to deliver the vendibles 104 to the customer 100 .
  • FIG. 3 illustrates one embodiment of a check approval process performed by the check acceptance service 110 in FIG. 2 .
  • the check approval process functionally describes one embodiment of risk assessment, wherein risk scores are utilized to evaluate the degree of risk such that, in marginal risk assessment cases, the risk system 150 may provide the merchant with provisional authorization in a manner as previously described. Additionally, low risk assessment cases are approved and high risk assessment cases are declined in a manner such that the approved or declined status may be based on customer check writing history or some other factor relevant to the risk assessment of the financial transaction between the merchant 106 and the customer 100 .
  • the check approval process initiates in a start state 200 and proceeds to a state 202 .
  • the risk system 150 obtains transaction data, information, and other details relating to the financial transaction from the merchant 106 via the interface 146 .
  • Related transaction information may include the customer's name, the customer's account number, and the amount of the promissory check or payment.
  • the check acceptance service 110 may obtain the customer's transaction information via the telephone, input on a web page via the internet, or by mail and transfer the information to the risk system 150 via keyboard input. Additionally in the state 202 , the check acceptance service 110 may access the merchant 106 record, such as transaction history with a particular customer, and determines the merchant's parameters.
  • the merchant parameters may include thresholds or classifications for determining low, marginal, and high risk assessment values.
  • the merchant parameters may further include desired risk engines, internal databases, and external databases to use when evaluating risk for a particular financial transaction.
  • the merchant record and parameters may be saved in a memory device and accessed whenever the merchant requests approval for a financial transaction.
  • the risk system 150 pre-processes the transaction information by generating an initial risk assessment for the financial transaction. Based on the initial risk assessment, the risk system 150 utilizes the risk scoring risk engine 154 to obtain an initial risk score in a manner that will be described in greater detail herein below. Then, the check approval process advances to a decision state 206 .
  • the risk system 150 performs the initial risk assessment in the state 204 as follows. In the state 204 , the risk system 150 receives transaction variables and merchant parameters from the interface 146 . Then following, the risk system 150 may access the internal database 156 for the transaction records of the customer 100 and the merchant 106 . Next, the risk system 150 may decide whether to proceed with the risk evaluation, based on the pre-score rules as described in the Applicant's co-pending U.S. patent application entitled “SYSTEMS AND METHODS FOR SELECTIVE USE OF RISK MODELS TO PREDICT FINANCIAL RISK”, Attorney Docket No. 1DATA.045A.
  • a hard negative decision or high risk assessment may lead to an automatic return of an applicable result to the interface 146 . Additionally, it should be appreciated that a hard negative or high risk assessment corresponding to the customer 100 may automatically lead to a decline decision status without further action by the risk system 150 .
  • a positive decision leads the risk system 150 to evaluate the financial transaction and select a scoring engine to run based on the transaction variables and the rules of the scoring rule matrix as described in the Applicant's co-pending U.S. patent application entitled “SYSTEMS AND METHODS FOR SELECTIVE USE OF RISK MODELS TO PREDICT FINANCIAL RISK”, Attorney Docket No. 1DATA.045A.
  • the scoring engine 154 of the risk system 150 scores the transaction risk and returns the risk score in a state 212 .
  • the risk system 150 evaluates the risk score based on the post-score rules, as described in the Applicant's co-pending U.S. patent application entitled “SYSTEMS AND METHODS FOR SELECTIVE USE OF RISK MODELS TO PREDICT FINANCIAL RISK”, Attorney Docket No. 1DATA.045A, and determines whether to perform additional risk assessment or suspend the financial transaction for further evaluation, in which case a provisional authorization may be provided to the merchant 106 as previously described. It should be appreciated that a negative decision by the risk system results in the transference of the applicable result to the interface. Otherwise, a positive decision leads the risk system 150 to select another scoring engine for an additional risk assessment.
  • the risk system 150 may access external databases for additional transaction information if necessary, and the risk system 150 may perform additional risk modeling or assessment with the selected scoring engine. In addition, the additional risk score resulting from the additional risk modeling may then be evaluated by the risk system 150 based on the post-score rules. At this point, the risk system 150 may determine whether further risk assessment is needed and return the applicable result to the interface 146 .
  • the additional risk assessment is performed in a manner such that the applicable result is returned after at least two risk assessments. In another embodiment, the additional risk assessment is performed one or more times as needed. It should be appreciated that selective actions taken by the risk system 150 according to the post-score rules may be considered consistent with the scope of the present invention. Thus, even if no additional risk assessment if performed based on the initial risk score and the post-score rule, such as the initial risk score being of high risk or of low risk for example, the selective decision process performed by the risk system is consistent with one aspect of the present invention described herein. It should also be appreciated that, based upon the initial risk score and/or the additional risk score, provisional authorization may be provided to the merchant 106 for the purpose of delaying the delivery of services and/or merchandise in a manner as previously described.
  • the check approval process advances to the decision state 206 .
  • the risk system 150 determines the degree of the generated risk score.
  • the risk system 150 may compare the initial risk score with a pre-determined range of a low risk assessment threshold. If the processor 162 determines from the comparison that the financial transaction is of low risk, then the check approval process advances to a state 208 to approve the financial transaction. Subsequently, in a state 210 , the check acceptance service 110 notifies the merchant 106 to deliver the vendibles, and then the check approval process terminates in an end state 220 .
  • the pre-determined range of the low risk assessment threshold may comprise any range of values or parameters set by the merchant 106 , the check acceptance service 110 , and/or any other guidelines available without departing from the scope of the present invention.
  • the check approval process advances to another decision state 212 .
  • the decision state 212 if the risk system 150 compares the initial risk score with a pre-determined range of a marginal risk assessment threshold. If the risk system 150 determines from the comparison that the financial transaction is not of marginal risk, then the check approval process advances to a state 218 to decline the financial transaction. In which case, the check approval process terminates in the end state 220 .
  • the pre-determined range of the marginal risk assessment threshold may comprise any range of values or parameters set by the merchant 106 , the check acceptance service 110 , and/or any other guidelines available without departing from the scope of the present invention.
  • the check approval process proceeds to a state 214 .
  • the check acceptance service 110 provides the merchant 106 with a provisional authorization in a manner as previously described.
  • provisional authorization provides the check acceptance service 110 additional time in a state 214 for further risk assessment, evaluation, and analysis.
  • the risk system 150 performs the provisional authorization process in a manner that will be described in greater detail herein below in reference to FIGS. 4, 5 .
  • the check approval process advances to the state 208 , where the check acceptance service 110 authorizes the financial transaction between the merchant 106 and the customer 100 . Then, the merchant 106 is notified by the check acceptance service 110 to deliver the vendibles in the state 210 , which is followed by the end state 220 . However, if the approval is not granted to the merchant 106 in the decision state 216 , then the risk system 150 declines the financial transaction in the state 262 , and the check approval process terminates in the end state 264 .
  • the risk system 150 performs an additional risk score assessment after the initial risk score prior to performing the provisional authorization process in the state 214 .
  • the risk system 150 may perform a plurality of additional risk assessments for the purpose of more accurately assessing the degree of risk of the financial transaction.
  • multiple risk assessments may be performed, for example, on financial transactions that involve large check draft amounts. It should be appreciated that the risk system 150 may perform any number of additional risk assessments on any number of types of financial transactions without departing from the scope of the present invention.
  • the above-mentioned risk assessment procedure, method, and system represents a significant improvement over traditional check handling procedures that automatically approve or decline borderline or marginal risk assessments. Additionally, the above-mentioned risk assessment method and system utilizes an efficient and selective mechanism for evaluating borderline or marginal exception conditions, such as the provisional authorization process. In one aspect, if borderline exception conditions or marginal risk assessment situations arise, the above-mentioned check acceptance procedure, method, and system selectively delays the delivery of services and/or merchandise prior to authorizing the financial transaction.
  • FIG. 4 illustrates one embodiment of a provisional authorization process that is utilized to evaluate marginal risk assessments.
  • the provisional authorization process as described herein below, is one embodiment of a functional process flow description of the state 214 in FIG. 3 .
  • financial transactions that involve promissory payments and marginal risk assessments may require a period of time for further risk evaluation or the verification of funds prior to the release of services and/or merchandise by the merchant 106 .
  • Some merchants 106 may elect to be classified by the check acceptance service 110 as capable of delaying the delivery of services and/or merchandise for the purpose of re-evaluating the marginal risk assessments of borderline risk based customers 100 .
  • Sometimes a marginally risky customer 100 may make good on their promissory payments. Therefore, a merchant 106 increases its profitability by accepting some marginally risky financial transactions by utilizing the provisional authorization process.
  • the provisional authorization process initiates in a start state 230 , and then advances to a state 232 , where the check acceptance service 110 obtains transaction information in a manner as described in the state 202 in FIG. 3 .
  • the check acceptance service 110 accesses the merchant 106 record, such as transaction history with the particular customer 100 , and determines the merchant's parameters in a manner as described in the state 202 in FIG. 3 .
  • the check acceptance service 110 determines from the merchant parameters whether the merchant 106 is classified as capable of delaying delivery of services and/or merchandise as previously described in reference to FIGS. 1, 2 .
  • merchants may selectively elect to be classified by the check acceptance agency as either being capable of delaying delivery or not capable of delaying delivery.
  • the merchant classification may comprise an electronic listing in the internal database 156 or part of the merchant transaction information and/or merchant parameters. Therefore, in the decision state 236 , the risk engine 152 may be utilized by the check acceptance service 110 to access the electronic listing in the internal database 156 and perform the determination.
  • the provisional authorization process advances to a state 248 , where the financial transaction may be declined. Moreover, if the financial transaction is declined in the state 248 , the declined results are electronically transferred to the merchant 106 via the interface 146 , and the provisional authorization process terminates in an end state 252 . It should be appreciated that the merchant 106 may be notified of the applicable results of the financial transaction via the telephone, satellite relay, standard mail, or the internet without departing from the scope of the present invention.
  • the provisional authorization process advances to a state 238 , where the check acceptance services 110 provides provisional authorization to the merchant 106 in a manner as previously described, such as electronically via the interface 146 or by telephone.
  • the check acceptance service 110 is given a period of time, ranging anywhere from a few minutes to several days, to perform additional risk assessment and evaluation in a state 240 .
  • additional risk assessment and evaluation may include verifying the existence of funds in the customer's check issuing bank account in a manner as described in FIG. 1 .
  • obtaining additional financial information about the customer in the state 240 may also comprise obtaining information about the customer's recent check writing history and evaluating the customer's recent check writing history to predict whether there will be sufficient funds to cover the cost of the financial transaction.
  • the customer's check writing history may be logged in the internal database 156 , the external database 160 , and/or saved as a merchant parameter.
  • a notification of provisional authorization informs the merchant 106 that additional risk assessment and evaluation is necessary.
  • the merchant 106 may either delay delivery until the check acceptance service 110 issues a notification of authorization for the financial transaction, or the merchant 106 may elect to deliver the services and/or merchandise after a pre-determined period of time if authorization notification was not issued by the check acceptance service 110 during the pre-determined period of time.
  • the pre-determined period of time may include any length of time ranging from a few seconds to a few weeks.
  • the merchant 106 upon receiving the provisional authorization notification, the merchant 106 knows to delay the delivery of services and/or merchandise until further risk analysis is performed by the check acceptance service 110 . It should be appreciated that authorizing delivery after the pre-selected period of time may include agreeing with the merchant 106 that unless the merchant 106 is advised to not deliver the service and/or merchandise at the end of the pre-selected period of time, the delivery of the merchandise is authorized.
  • the additional risk assessment and evaluation may require obtaining additional transaction information from the customer 100 , such as a driver's license number, a date of birth, a social security number, previous residential addresses, and/or recent check writing history.
  • additional transaction information such as a driver's license number, a date of birth, a social security number, previous residential addresses, and/or recent check writing history.
  • the check acceptance service 110 may perform a more in depth risk assessment by generating additional risk scores and accessing more external databases for credit history evaluation, which may result in more successfully avoiding fraud based financial transactions.
  • approval may be determined in another decision state 242 . If the check acceptance service 110 approves the financial transaction in the decision sate 242 , the financial transaction is authorized in a state 244 , and the approval results are transferred to the merchant 106 in the state 250 in a manner as previously described. Next, the provisional authorization process terminates in the end state 252 .
  • the check acceptance service 110 may decide to perform more additional processing of the risk assessment. This additional processing may include verifying funds in the customer's bank account or waiting for the check to cleared in a check clearing process in a manner as previously described. If additional processing may be performed, then the processing is performed in the state 240 . Otherwise, if additional process may not be performed the financial transaction is declined in the state 248 , the applicable results are sent to the merchant 106 , and the provisional authorization process terminates in the end state 252 .
  • the provisional authorization process may be utilized to increase revenue in financial transactions where marginal risk assessments occur.
  • internet and mail order based merchants may substantially increase profits by integrating the provisional authorization process into practice.
  • customers that order vendibles, such as services and/or merchandise, over the internet often expect to wait for delivery.
  • the internet is one embodiment of a preferred application of the provisional authorization process, which will be described in greater detail herein below in FIG. 5 .
  • FIG. 5 illustrates one example of an application of the provisional authorization process in FIG. 4 to an internet based financial transaction.
  • the internet based provisional authorization process as described herein below, is one embodiment of a functional process flow description of the state 214 in FIG. 3 and the provisional authorization process in FIG. 4 .
  • internet based financial transactions that involve promissory payments, electronic or otherwise, and marginal risk assessments may require a period of time for further risk evaluation or the verification of funds prior to the release and delivery of services and/or merchandise.
  • internet based merchants 106 are usually classified by the check acceptance service 110 as capable of delaying the delivery of services and/or merchandise.
  • the typical internet based merchant 106 may substantially increase profitability by accepting some marginally risky financial transactions via the utilization of the provisional authorization process as described in FIG. 4 .
  • the internet based provisional authorization process initiates in a start state 260 .
  • the check acceptance service 110 electronically obtains transaction information from the customer 100 via the merchant's web page or an email attachment. For privacy reasons, sometimes a customer 100 may choose to submit transaction information via the telephone.
  • the check acceptance service 110 electronically obtains the merchant record and parameters from the internal database 156 .
  • the check acceptance service 110 determines in a decision state 266 that delivery of vendibles 106 may be delayed.
  • the check acceptance service 110 previously determined that the internet based financial transaction is marginally risky by utilizing the check approval process in FIG. 3 . It should be appreciated that a low risk assessment results in approval, and a high risk assessment results in a decline.
  • the check acceptance service 110 provides provisional authorization to the merchant 106 in a state 268 , which notifies the merchant 106 to delay delivery of the vendibles 106 until funds in the customer's banking account are verified in a state 270 .
  • the check acceptance service 110 seeks funds through the automatic clearing house (ACH) as previously described in FIG. 1 .
  • the check acceptance service 110 may contact via the telephone the customer's check issuing bank 116 to verify funds in the customer's banking account.
  • the internet based financial transaction is approved in a state 274 , the merchant 106 is notified via telephone, email, or otherwise to deliver the vendibles 106 to the customer 100 , and the internet based provisional authorization process terminates in an end state 282 . Otherwise, in the decision state 272 , if the funds are not available in the customer's banking account, then the financial transaction is declined in a state 278 , and the merchant 106 is notified via telephone, email, or otherwise to cancel the delivery of the vendibles 106 to the customer 100 in a state 280 . Following the state 280 , the internet based provisional authorization process terminates in the end state 282 .
  • the above-mentioned risk assessment procedure, method, and system represents a significant improvement over traditional check handling procedures that automatically approve or decline marginally risky financial transactions or require the transfer of a paper check among various financial institutions.
  • the above-mentioned risk assessment method and system utilizes an efficient and selective mechanism for evaluating borderline exception conditions and marginal risk assessments, such as utilizing the provisional authorization process in borderline risk transactions with marginal risk scores.
  • the above-mentioned check acceptance procedure, method, and system selectively delays the delivery of services and/or merchandise prior to authorizing the financial transaction in a manner such that the customer is marginally inconvenienced, the merchant retains the vendibles, and the check acceptance service reduces the potential loss of funds.

Abstract

A risk system that performs a risk assessment of a financial transaction to obtain an initial risk score. Based on the initial risk score, the risk system performs at least one post-score assessment by selectively utilizing various scoring engines and databases. The at least one post-score risk assessment may include delaying the shipment of merchandise in financial transactions that are of marginal risk to thereby provide a check acceptance service with more time to further evaluate the financial transaction risks. Thus, marginally risky financial transactions that are likely to benefit the check acceptance service and a merchant that subscribes to the check acceptance service are authorized for increased profitability and customer satisfaction. Furthermore, the post-score risk assessment may approve or authorize financial transactions that generally fail standard risk assessments that use a cut-off risk score to divide the financial transactions into either approved or declined groups. As a result, the post-score assessment process efficiently re-evaluates some of the borderline exception cases for the purpose of securing beneficial financial transactions.

Description

    PRIORITY APPLICATION
  • This application is a continuation of U.S. application Ser. No. 10/041,954, titled “Systems and Methods for Selectively Delaying Financial Transactions”, filed on Jan. 7, 2002, the entirety of which is incorporated herein by reference.
  • BACKGROUND OF THE INVENTION
  • 1. Field of the Invention
  • The present invention relates to financial transactions and, in particular, to a system and method of risk assessment, whereby provisional authorization may be granted to a merchant for the selective delay of a financial transaction.
  • 2. Description of the Related Art
  • A typical financial transaction involves a form of payment in exchange for vendibles, such as services and/or merchandise, at a point of sale. In most instances, a customer provides the form of payment, such as a promissory check draft, to a merchant in exchange for the vendibles. The check draft is often regarded as a promissory payment that instructs the customer's bank to pay the merchant. As is generally known, the funds promised to the merchant by the check draft are sometimes not paid due to reasons, such as insufficient funds in the customer's checking account or fraud. Unfortunately, the merchant may be susceptible to risk whenever a check draft is received as payment for services and/or merchandise.
  • Sometimes, the merchant may choose to manage risk by maintaining one or more local databases that may include, for example, a list of customers or check writers that have written bad checks in the past. Such databases may range from a simple list on paper for a small store owner to a computer network for a chain store. Unfortunately, managing such databases requires use of merchant resources that could otherwise be used more beneficially.
  • Alternatively, the merchant may choose to manage risk by subscribing to an agency that assess the risk associated with promissory check related financial transactions. Examples of a risk assessment agency include TeleCheck. For a given transaction, a subscribed merchant sends a transaction approval request to the agency with information, such as promissory check draft amount, check identifying information, and information about the check writer. The agency assesses the risk and generates a risk score based on the information received. The agency then either approves or declines the transaction based on the generated risk score. The level of subscription to such an agency may vary, from an approval service to the agency assuming the risk of the transaction by either guaranteeing the check or purchasing the check from the merchant. Thus, it is in the interest of the agency to accurately assess the risks associated with financial transactions.
  • A conventional check approving process may comprise a cutoff risk score such that a transaction whose risk score is higher than the cutoff risk score is approved. Conversely, a transaction whose risk score is lower than the cutoff risk score is declined. In addition, a borderline risk score is positioned somewhere between the low risk score and the high risk score, which is somewhat near the cutoff risk score. Consequently, since the above-mentioned check approval process is generally configured to statistically favor the merchant or the check approving agency in terms of probable risk, borderline risk assessments are often declined in many check transactions that correspond to borderline risk scores.
  • For example, if the generated risk score is substantially equivalent to the cutoff risk score, which corresponds to a borderline or marginal risk score, then the merchant and/or the check approving agency typically declines the financial transaction and the customer is required to present another form of payment or abandon the requested financial transaction altogether. In many cases, marginal risk situations result in lost revenue for the merchant due to the occurrence of borderline or marginal risk assessment declines.
  • In certain high risk environments, it may be necessary to issue a high number of risk based declines to protect the merchant and the check approving agency from high returned check rates. Unfortunately, issuing the high number of risk declines results in customers becoming irate, merchants losing sales, and interferes with the check approving agency's ability to assess marginal risk at higher turndown levels. Therefore, some conventional check approval agencies are substantially deficient in managing marginal risk and may require significant improvement. Furthermore, the authorizational processing, temporal risk, and lack of flexibility to manage procedural variations and/or borderline risk scores by conventional check approval agencies may also require significant improvement.
  • SUMMARY OF THE INVENTION
  • The present invention provides a method and system which selectively delays the financial transaction until further transaction information may be obtained and processed for review and evaluation in borderline or marginal risk assessment situations. In one embodiment, a method of assessing risk associated with a financial transaction is described herein below, wherein a customer is attempting to pay for vendibles from a merchant via a promissory payment. The method comprises, first, receiving transaction information from the merchant at a point of sale, wherein the transaction information identifies the customer, the merchant, and includes data about the financial transaction. Next, the method further comprises assessing the risk of the financial transaction using at least one mathematically based scoring engine to obtain a risk value.
  • Additionally, the method further comprises determining if the risk value indicates that the risk is in a first classification of risk wherein additional information about the customer may result in the risk value being positioned within a second classification of risk for which acceptance of the promissory payment as payment for the vendibles is warranted. Moreover, the method comprises provisionally authorizing acceptance of the promissory check if the risk value determination indicates that the risk value is in the first classification, and communicating the provisional authorization to the merchant at the point of sale to thereby indicate to the merchant to accept the tendered promissory payment but to hold delivery of the vendibles for a pre-selected period of time.
  • Furthermore, the method comprises obtaining additional financial data about the customer during the pre-selected period of time to determine if the risk value can be positioned within the second classification, and authorizing delivery of the vendibles after the pre-selected period of time when the additional financial data about the customer indicates that the risk value can be positioned in the second classification.
  • In one aspect, the method may further comprise determining if the merchant is a merchant who can delay delivery of the vendibles and wherein communicating the provisional authorization to the merchant occurs only if the merchant is determined to be a merchant who can delay delivery of the vendibles. In addition, assessing risk associated with the financial transaction may correspond to assessing risk associated with an internet based financial transaction and/or a mail order based financial transaction.
  • In another aspect, authorizing delivery after the pre-selected period of time may comprise contacting the merchant and advising the merchant to deliver the vendibles and wherein authorizing delivery after the pre-selected period of time comprises agreeing with the merchant that unless the merchant is advised to not ship at the end of the pre-selected period of time, the delivery of the vendibles is authorized. Additionally, the pre-selected period of time may range from at least one micro-second to a few weeks.
  • In still another aspect, obtaining additional financial information about the customer may comprise verifying availability of funds in a checking account belonging to the customer to cover the cost of the financial transaction. In addition, obtaining additional financial information about the customer may further comprise obtaining information about the customer's recent check writing history and evaluating the customer's recent check writing history to predict whether there will be sufficient funds to cover the cost of the financial transaction. Moreover, attempting to pay via the promissory payment may comprise attempting to pay via a check, an electronic check, and/or a paper check, and wherein attempting to pay for vendibles may comprises attempting to pay for services and/or merchandise.
  • In yet another aspect, determining if the risk value indicates that the risk is in the first classification may comprise assessing a marginal risk assessment, wherein the marginal risk assessment is between a low risk assessment and a high risk assessment. Also, determining if the risk value indicates that the risk is in the second classification may comprise assessing a low risk assessment.
  • In another embodiment, a system of assessing risk associated with a financial transaction is described herein below, wherein a customer is attempting to pay for vendibles from a merchant via a promissory payment. The system comprises a risk assessment component that is configured to perform a risk assessment of the financial transaction using at least one scoring engine to generate a risk score based on transaction information obtained from the merchant via an interface component, wherein the transaction information identifies the customer, the merchant, and includes data about the financial transaction.
  • In addition, the system further comprises a processing component that is configured to determine a marginal risk assessment if the risk score is in a borderline classification of risk, wherein additional customer information may result in the risk score being positioned within a low classification of risk for which acceptance of the promissory payment for the vendibles is authorized.
  • Moreover, the system further comprises a communications component that is configured to communicate with the merchant, wherein the communication component notifies the merchant at the point of sale, and wherein the notification instructs the merchant to accept the tendered promissory payment but to delay delivery of the vendibles for a period of time, wherein, during the period of time, additional financial data about the customer is obtained via the interface device to re-assess the risk associated with the financial transaction.
  • In one aspect, the system may comprise an authorization component that is configured to authorize delivery of the vendibles after the period of time when the additional financial data about the customer indicates that the risk score can be re-positioned in the low classification of risk. The authorization component may further comprise a communications device and contacts the merchant via communications medium and advises the merchant to deliver the vendibles to the customer. The authorization component may be used to authorize the delivery of the vendibles after the period of time unless the merchant is advised to not ship at the end of the period of time by the authorization component. Also, the period of time ranges from at least one micro-second to a few weeks.
  • In another aspect, the processing component is further configured to determine if the merchant is a merchant who can delay delivery of the vendibles, wherein the processing component determines the marginal risk assessment only if the merchant is determined to be a merchant who can delay delivery of the vendibles. Additionally, the financial transaction is an internet based financial transaction and/or a mail order based financial transaction.
  • In another aspect, the system is may be configured to acquire additional customer information and verify the availability of funds in a checking account belonging to the customer to cover the cost of the financial transaction, wherein the additional customer information comprises transaction information about the customer's recent check writing history. In addition, the processing component may also be configured to evaluate the customer's recent check writing history to predict whether there will be sufficient funds to cover the cost of the financial transaction.
  • These and other objects and advantages of the present invention will become apparent from the following description taken in conjunction with the accompanying drawings.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • These and other aspects, advantages, and novel features of the invention will become apparent upon reading the following detailed description and upon reference to the accompanying drawings. In the drawings, similar elements have similar reference numerals.
  • FIG. 1 illustrates one embodiment of a financial transaction involving a check draft and a check acceptance service.
  • FIG. 2 illustrates one embodiment of a schematic block diagram of the check acceptance service in FIG. 1 including a risk system and a Model/Action/Rules processor.
  • FIG. 3 illustrates one embodiment of a check approval process flow that describes the implementation of one aspect of the present invention by the check acceptance service in FIG. 2.
  • FIG. 4 illustrates one embodiment of a risk assessment process flow that utilizes the risk system, as referenced by FIG. 2, to selectively re-assess the transaction variables, parameters, and information relevant to the financial transaction.
  • FIG. 5 illustrates one embodiment of a check approval process performed by the Model/Action/Rules processor as referenced by the risk system in FIG. 2.
  • DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
  • Reference will now be made to the drawings wherein like numerals refer to like parts throughout. FIG. 1 illustrates one embodiment of a financial transaction involving a promissory check draft. In this particular embodiment, a customer 100 provides the check draft 102 to a merchant 106 or service entity in exchange for vendibles 104, such as a service or merchandise. The check draft 102 may be accepted and deposited into a merchant bank 112 without receiving any external authorization as indicated by path 120.
  • In one aspect, the check draft 102 is electronically transferred through a clearing process, wherein the merchant bank 112 transfers the check draft 102 to a federal clearing house (FCH) 114 as indicated by path 122. In turn, the federal clearing house 114 transfers the check draft 102 to the check issuing bank 116 as indicated by path 124. In one aspect, if the check draft 102 is determined to be valid by the check issuing bank 116, then the check “clears” and the amount of the check 102 is debited from the customer's 100 checking account in the check issuing bank 116, and the debited amount is subsequently transferred to the merchant's 104 account in the merchant bank 112 as indicated by path 126.
  • In some financial transactions, the check draft 102 may not clear for various reasons. As a result, the merchant's 106 bank account is not credited with the check amount. For example, the check issuing bank 116 may provide a non-sufficient fund (NSF) statement corresponding to the customer's 102 checking account, a stop payment request by the customer 100, and/or a fraudulent check issuance. Unfortunately, if the check draft 102 fails to clear, the merchant 106 is left with the responsibility of collecting the proper funds or the vendibles 104 from the customer 100. In some instances, the merchant 106 may be unsuccessful in reclaiming the proper funds in a collection process, and the already released merchandise may be written off as a loss.
  • Alternatively, even when the merchant is successful in reclaiming the funds, the collection process significantly increases the merchant's 106 costs associated with the financial transaction. To reduce the occurrence of further loss from the same “bad” check writer or customer 100, the customer's 102 name may be added to a negative list, such as an internal or local database. However, the local database may offer only limited protection against “bad” check writers, who may have previously bounced checks in the merchant's 106 establishment. Furthermore, “bad” check writers, who may not have previously bounced checks in the merchant's 106 establishment, but have a history of bouncing checks or writing fraudulent checks elsewhere, are unlikely to be detected by such a local database.
  • As a consequence, most merchants decide to subscribe to and rely on a check acceptance service 110 to manage risks associated with accepting checks from customers. The interaction between the merchant 106 and the check acceptance service 110 is indicated by path 130. It should be appreciated that the scope of a subscription service that the merchant 106 subscribes to may vary depending on the needs of the merchant 106.
  • In one embodiment, the subscription service may comprise the process of the check acceptance service 110 informing the merchant 106 to accept or refuse the check 102 based on the risk associated with the particular financial transaction. If the check draft 102 is approved and accepted, the check draft 102 is then transferred through the clearing process via the merchant bank 112 in a manner similar to that described above. Unfortunately, if the clearing process is not completed successfully, the merchant 106 usually assumes the risk associated with the financial transaction.
  • Another embodiment of the subscription service may comprise the process of the check acceptance service 110 guaranteeing the validity of the check 102 based on the risk associated with the particular financial transaction. In this particular embodiment, the check draft 102 is transferred through the clearing process via the merchant bank 112 in a manner similar to the previous description. Fortunately for the merchant 106, if the check 102 fails to clear, the check acceptance service 110 credits the merchant 106 for the amount of the check draft 102 and assumes the responsibility of collecting the funds from the customer 100.
  • Still another embodiment of the subscription service may comprise the process of the check acceptance service 110 purchasing the check draft 102 outright from the merchant 106 based on the risk associated with the financial transaction. Beneficially, in this particular embodiment, the merchant 106 receives payment for the financial transaction upon approval or authorization from the check acceptance service 110. Furthermore, in some cases, the check acceptance service 110 may be electronically linked to the merchant bank 112, as indicated by path 136, to electronically transfer the necessary funds.
  • In one aspect, the check acceptance service 110 assumes the responsibility of clearing the check draft 102. For example, the check draft 102 may be transferred from the check acceptance service 110 to the federal clearing house (FCH) 114 as indicated by path 132. Then, the check draft 102 may be transferred to the check issuing bank 116 as indicated by the path 124. In this particular embodiment, if the check 102 is valid or validity may be verified, the necessary funds are transferred from the check issuing bank 116 to the check acceptance service 110 as indicated by path 134.
  • At this point, the financial transaction is regarded as complete for the check acceptance service 110. However, if the check draft 102 fails to clear with the check issuing bank 116 of the customer 100, then the check acceptance service 110 assumes the responsibility of collecting the necessary funds from the customer 100.
  • Various subscription services comprise diverse fee schedules that are significantly determined by the risks associated with the encountered financial transactions. It should be appreciated that the success of the check acceptance service 110, including profitability, may substantially depend on accurate risk assessments that may be associated with check related financial transactions. For example, if the check acceptance service 110 provides misguided or erroneous approval decisions to the merchant 106, then the merchant 106 accepts high risk check drafts and/or refuses beneficial customers, which may result in lost revenue or dissatisfied customers. In other situations, the risk is assumed by the check acceptance service 106, and profitability is directly related to the accuracy of risk assessments.
  • In one embodiment, the technology associated with financial transactions and the electronic transfer of funds by a central financial transaction entity or the check acceptance service 110 include monetary exchange devices, such as check readers, credit card readers, debit card readers, manual input of account information, or some combination thereof for the purpose of obtaining authorization for and settlement of financial transactions at the point of sale. In addition, financial transfer systems may include a point of sale terminal, which may include a display monitor, a printer, magnetic card reader, and a magnetic check reader.
  • For example, the check draft 102 or a credit card may be presented by the customer 100 to the merchant 106 and swiped through the check reader or magnetic card reader, respectively. In one aspect, the check reader portion of the point of sale terminal identifies, by either magnetic ink character recognition (MICR) or optical character recognition (OCR), the American Banking Association (ABA) account information printed on the face of the check draft 102 or stored in the magnetic strip of the credit card, respectively, and converts the customer's ABA account information to transactional data, which may include digital signals or digital signatures pertaining to the financial transaction.
  • Transactional data may also include customer 100 identification information, wherein the customer 100 may be required to provide identification, such as a driver's license, or the customer 100 may then be prompted to enter a personal identification number (PIN) associated with corresponding account. The merchant 106 may then enter the pertinent sale data that indicates the amount of the transaction to be authorized, wherein this information may also be converted into transactional data. The resulting collective transactional data is then transferred to the check acceptance service 110 for additional authorizational processing and evaluation. In one aspect, additional authorizational processing and evaluation may include verifying the existence of finds in the customer's check issuing bank account in a manner as described in FIG. 1. Furthermore, obtaining additional financial information about the customer may also comprise obtaining information about the customer's recent check writing history and evaluating the customer's recent check writing history to predict whether there will be sufficient funds to cover the cost of the financial transaction. The customer's check writing history may be logged in an internal database, an external database, and/or saved as a merchant parameter in a memory component.
  • Additionally, transaction information, including merchant information and customer information, relating to approved and/or declined financial transactions is recorded in a data warehouse of the central financial transaction entity or the check acceptance service 110 for the merchant's 106 future reference, wherein the check acceptance service 110 may generally update transactional information on a daily basis in a batch process, and daily reports may be generated to provide both detailed and summary records of transaction information. Once the transactional data is transferred and received, the check acceptance service 110 may begin authorizational processing by verifying the transactional data with authorization algorithms that may use an ABA account number-PIN pair database and a review of funds verification.
  • In one aspect, the ABA account number-PIN pair database or some other internal database maintains a file of ABA account information and the personal identification numbers corresponding to respective accounts. In another aspect, the review of funds verification is a system adapted to bi-directionally communicate with a financial institution, such as the check issuing bank 116 to determine that sufficient funds exist in the customer's account for the desired financial transaction.
  • Alternatively, the check acceptance service 110 may provide provisional authorization 140, in marginal risk assessment situations, to the merchant for the financial transaction. In one embodiment, provisional authorization 140 allows the check acceptance service 110 to selectively re-evaluate the customer's transaction information prior to an approval or decline. In addition, provisional authorization 140 allows the merchant to delay delivery of the vendibles 104 until further risk assessment and/or analysis is processed by the central financial transaction entity or the check acceptance service 110. Advantageously, instead of issuing automatic risk declines for financial transactions that may be categorized as marginally risky, the check acceptance service 110 may provide the merchant 106 a response indicating provisional authorization 140. In some cases, the merchant 106 avoids issuing marginal risk declines, which results in customer satisfaction and increased sales.
  • Next, the check acceptance service 110 records the MICR information and generates a transactional identification number. If the personal identification number is determined to correspond to the account number and sufficient funds are available in the account, an approval number is assigned to the financial transaction. Additionally, the check acceptance service 110 generates electronic debit and credit files for submission to an automated federal clearing house (FCH) 114 or federal reserve network computer. These electronic files instruct the customer's bank 116 or the paying financial institution to deposit the necessary funds in the merchant's bank 112 or the depositing financial institution. The FCH 114 or federal reserve computers execute the debit and credit file instructions, and the paying financial institution accordingly deposits the customer's funds into the depositing financial institution. Upon receipt by the point of sale terminal of an approval message for the financial transaction, the merchant may issue an instruction to void the financial transaction or to reverse the previous financial transaction instruction in a manner such that the previous instruction credits the merchant's 106 account or credits the customer's 100 account.
  • In one aspect, a significant advantage is achieved with internet and mail order based financial transactions, where a delivery delay of the vendibles 104 is likely to occur in certain situations. In some instances, a customer 100 may choose to mail a paper check in exchange for ordered vendibles 104, and therefore the customer 100 expects to wait a period of time for delivery. At the time of order, the check acceptance service 110 may obtain transaction information from the customer 100 and verify the existence of funds electronically prior to receiving the paper check. While the paper check is in route to the check acceptance service 110 through standard mail, the check acceptance service 110 may perform various risk assessments, and, depending on the risk assessment, the check acceptance service 110 may notify the merchant 106 to deliver the vendibles 104 or withhold the vendibles 104 until the funds are verified the customer's 100 account. In marginal risk assessment situations, the check acceptance service 110 may provide provisional authorization to the merchant 106, which informs the merchant 106 to delay the delivery of vendibles 106 until further risk assessment is performed. Without departing from the scope of the present invention, it should be appreciated that, at the time of order, the customer 100 may elect to submit an electronic check to the check acceptance service 110 via the merchant 106 in exchange for vendibles 106, wherein the check may be processed electronically.
  • Advantageously, the above-mentioned financial transfer system represents a significant improvement over traditional check handling procedures that require the transfer of a paper check among various financial institutions. For example, the above-mentioned financial transfer system includes a mechanism for determining borderline or marginal exception conditions, such as utilizing provisional authorization 140 in borderline or marginal risk situations. If borderline exception conditions or marginal risk assessment situations arise, the above-mentioned financial transfer system suggests the delivery delay of vendibles 104 prior to authorizing the financial transaction in a manner such that the customer 100 is marginally inconvenienced, the merchant retains the merchandise, and the check acceptance service reduces the potential loss of funds.
  • FIG. 2 illustrates one embodiment of a schematic block diagram of the check acceptance service 110 of FIG. 1. In addition, FIG. 2 further illustrates interaction of the check acceptance service 110 with the merchant 106 and the customer 100 in determining the risk associated with a financial transaction. In one aspect, the merchant 106 receives the check draft 102 from the customer 100, and the merchant 106 electronically interacts with the check acceptance service 110 to determine if the check draft 102 will be accepted or declined. The interaction comprises financial transaction details 142 submitted by the merchant 106 to the check acceptance service 110, and an approve or decline decision 144 provided by the check acceptance service 110 to the merchant 106. The financial transaction details 142 and the approve or decline decision 144 are described in greater detail herein below.
  • In one aspect, the check acceptance service 110 comprises a risk system 150 that evaluates the risk involved with a given transaction. The risk system 150 interacts with the merchant 106 via a electronic interface 146, such as a telephonic, satellite, and/or computer network (internet) interface. In particular, the interface 146 receives the financial transaction details 142 from the merchant 106 and passes on the information to the risk system 150. Then, the risk system 150 may evaluate the financial transaction in a manner described herein below and returns a decision to the interface 146, which is used to provide the merchant 106 with the desired approve or decline decision 144.
  • Additionally, the interface 146 may also access and retrieve relevant information about the customer 100, such as check writing history, and/or the merchant 106, such as limit on the check amount acceptable and other specific factors preferences, from an internal database 156 and evaluate the customer and/or merchant parameters so as to permit configuring the manner in which the risk assessment is performed by the risk system 150. Additionally, the risk system 150 is also configured so as to permit accessing of an external database 160, which may comprises a plurality of external databases 174 a, 174 b, etc. The external database 160 permits the risk engine 152 to gather relevant transaction information about the customer 100 and the merchant 106 that may not necessarily be available in the internal database 156, so as to further facilitate the risk assessment.
  • Moreover, the risk system 150 further comprises a risk engine 152 that evaluates the risk assessment of the financial transaction based on the financial transaction details 142 or transaction data transferred from the interface 146, the internal database 156, and the external database 160. In addition, the risk scoring engine 154 may determine a risk score at the request of the check acceptance service 110 and returns the risk score indicative of a probable risk assessment of the financial transaction. Advantageously, the risk scoring engine 154 may comprise a plurality of scoring engines 172 a, 172 b, 172 c, etc., wherein each risk engine is adapted to address a plurality of possible financial transactions or transaction variables in a manner so as to permit improved accuracy in determining the risk score. Various types of scoring engines that may be utilized by the risk engine will be described in greater detail herein below. In addition, a preferred financial transaction that illustrates selective use of the plurality of scoring engines will be described in greater detail herein below.
  • Furthermore, the risk engine 152 further comprises a Model/Action/Rules processor 162 that may be utilized to evaluate the transaction risk and may determine whether to approve or decline the financial transaction. The processor 162 comprises a pre-score rules module 164, a scoring rule matrix module 166, a post-score rules module, and a delay delivery module 168. The pre-score rules module 164 is utilized to initially determine whether risk evaluation needs to performed. For example, the risk engine may access the internal database 156 for transaction information about the customer, and ascertains that the customer 100 is associated with a hard negative check writing history. In this particular case, the hard negative check writing history arises from writing one or more non-clearable check drafts and, in some cases, refuses to provide legitimate compensation during the collection process. As a result, the pre-score rules module 164 may then decide that the financial transaction is of high risk and, in which case, subsequently declines authorization due to an unacceptable risk assessment ascertained for the customer 100.
  • Additionally, the scoring rule matrix module 166 includes a plurality of rules and utilizes the plurality of rules for the purpose of selecting a relevant scoring engine to obtain an initial risk score. Based on the initial risk score, the scoring rule matrix module 166 may approve or decline the financial transaction.
  • Furthermore, the post-score rules module 170 may be utilized to evaluate the initial risk score, that was generated by the scoring matrix 166, to determine if further risk assessment needs to be performed. In particular, the post-score rules module 170 may selectively determine a second scoring engine to run so as to obtain an additional risk score. In one embodiment, the additional risk score assessment is performed if the initial risk score leads to a transaction decline according to the scoring rule matrix 166. In another embodiment, the additional risk assessment is performed if the initial risk score falls within a predetermined range of risk score threshold values. It should be appreciated that the additional risk assessment performed selectively may be implemented in any number of situations so as to accurately assess the financial transaction risk.
  • In one aspect, examples and functionality of an exemplary risk assessment may be configured in accordance with methods described in the Applicant's co-pending U.S. patent application entitled “SYSTEMS AND METHODS FOR SELECTIVE USE OF RISK MODELS TO PREDICT FINANCIAL RISK”, Attorney Docket No. 1DATA.045A, which is incorporated herein by reference in its entirety. Some rules invoke other rules based on simple decisions, and some rules invoke scoring engines to determine risk related factors. It should be emphasized that the rules and the scoring engines illustrated and described in reference to the Applicant's co-pending application are not intended to limit the scope of the risk system. Thus, it should be appreciated that the rules and scoring engines exemplified in the Applicant's co-pending application illustrate one embodiment of the risk assessment associated with the financial transaction described herein below.
  • The delay delivery module 168 may be utilized to provide the merchant 106 with a notification of provisional authorization. In some cases, if the risk engine 152 determines that the financial transaction maintains a borderline or marginal risk exception condition, then the delay delivery module 168 may issue the notification of provisional authorization to the merchant 106. In one aspect, provisional authorization notifies the merchant 106 that additional risk assessment and evaluation is necessary. The merchant 106 may either delay delivery until the check acceptance service 110 issues a notification of authorization for the financial transaction, or the merchant 106 may elect to deliver the services and/or merchandise after a pre-determined period of time if authorization notification was not issued by the check acceptance service 110 during the pre-determined period of time.
  • Additionally, upon receiving the provisional authorization notification, the merchant 106 knows to delay the delivery of services and/or merchandise until further risk analysis may be performed by the risk system 150. In one aspect, it should be appreciated that authorizing delivery after the pre-selected period of time may include agreeing with the merchant 106 that unless the merchant 106 is advised to not deliver the service and/or merchandise at the end of the pre-selected period of time, the delivery of the merchandise is authorized. The advantage is that the merchant 106 retains the services or merchandise, the customer 100 is satisfied with the service, and the check acceptance service 110 is given additional time to evaluate further transaction information, including additional risk assessments, prior to approval or decline.
  • Advantageously, in financial transactions where the delivery of vendibles 104 may be delayed, such as internet and mail order based financial transactions, the use of provisional authorization inhibits the lost merchandise, dissatisfied customers, and lost revenue for marginal risk assessments. For example, after providing provisional authorization to the merchant 106, the risk system 150 may request additional information about the financial transaction from the merchant 106 and/or the customer 100 via the interface 146 for further risk assessment, or the risk engine 152 may re-score the risk associated with the financial transaction in the risk scoring engine 154. In addition, the risk system 150 may choose to electronically verify the existence of funds in the customer's 100 account prior to notifying the merchant 106 to deliver the vendibles 104 to the customer 100.
  • FIG. 3 illustrates one embodiment of a check approval process performed by the check acceptance service 110 in FIG. 2. The check approval process functionally describes one embodiment of risk assessment, wherein risk scores are utilized to evaluate the degree of risk such that, in marginal risk assessment cases, the risk system 150 may provide the merchant with provisional authorization in a manner as previously described. Additionally, low risk assessment cases are approved and high risk assessment cases are declined in a manner such that the approved or declined status may be based on customer check writing history or some other factor relevant to the risk assessment of the financial transaction between the merchant 106 and the customer 100.
  • The check approval process initiates in a start state 200 and proceeds to a state 202. In the state 202, the risk system 150 obtains transaction data, information, and other details relating to the financial transaction from the merchant 106 via the interface 146. Related transaction information may include the customer's name, the customer's account number, and the amount of the promissory check or payment. In one aspect, the check acceptance service 110 may obtain the customer's transaction information via the telephone, input on a web page via the internet, or by mail and transfer the information to the risk system 150 via keyboard input. Additionally in the state 202, the check acceptance service 110 may access the merchant 106 record, such as transaction history with a particular customer, and determines the merchant's parameters. The merchant parameters may include thresholds or classifications for determining low, marginal, and high risk assessment values. The merchant parameters may further include desired risk engines, internal databases, and external databases to use when evaluating risk for a particular financial transaction. The merchant record and parameters may be saved in a memory device and accessed whenever the merchant requests approval for a financial transaction.
  • Next, in a state 204 that follows, the risk system 150 pre-processes the transaction information by generating an initial risk assessment for the financial transaction. Based on the initial risk assessment, the risk system 150 utilizes the risk scoring risk engine 154 to obtain an initial risk score in a manner that will be described in greater detail herein below. Then, the check approval process advances to a decision state 206.
  • In one aspect, the risk system 150 performs the initial risk assessment in the state 204 as follows. In the state 204, the risk system 150 receives transaction variables and merchant parameters from the interface 146. Then following, the risk system 150 may access the internal database 156 for the transaction records of the customer 100 and the merchant 106. Next, the risk system 150 may decide whether to proceed with the risk evaluation, based on the pre-score rules as described in the Applicant's co-pending U.S. patent application entitled “SYSTEMS AND METHODS FOR SELECTIVE USE OF RISK MODELS TO PREDICT FINANCIAL RISK”, Attorney Docket No. 1DATA.045A. In most instances, a hard negative decision or high risk assessment may lead to an automatic return of an applicable result to the interface 146. Additionally, it should be appreciated that a hard negative or high risk assessment corresponding to the customer 100 may automatically lead to a decline decision status without further action by the risk system 150.
  • Alternatively, a positive decision leads the risk system 150 to evaluate the financial transaction and select a scoring engine to run based on the transaction variables and the rules of the scoring rule matrix as described in the Applicant's co-pending U.S. patent application entitled “SYSTEMS AND METHODS FOR SELECTIVE USE OF RISK MODELS TO PREDICT FINANCIAL RISK”, Attorney Docket No. 1DATA.045A. The scoring engine 154 of the risk system 150 scores the transaction risk and returns the risk score in a state 212.
  • In addition, the risk system 150 evaluates the risk score based on the post-score rules, as described in the Applicant's co-pending U.S. patent application entitled “SYSTEMS AND METHODS FOR SELECTIVE USE OF RISK MODELS TO PREDICT FINANCIAL RISK”, Attorney Docket No. 1DATA.045A, and determines whether to perform additional risk assessment or suspend the financial transaction for further evaluation, in which case a provisional authorization may be provided to the merchant 106 as previously described. It should be appreciated that a negative decision by the risk system results in the transference of the applicable result to the interface. Otherwise, a positive decision leads the risk system 150 to select another scoring engine for an additional risk assessment.
  • Following the selection of a scoring engine, the risk system 150 may access external databases for additional transaction information if necessary, and the risk system 150 may perform additional risk modeling or assessment with the selected scoring engine. In addition, the additional risk score resulting from the additional risk modeling may then be evaluated by the risk system 150 based on the post-score rules. At this point, the risk system 150 may determine whether further risk assessment is needed and return the applicable result to the interface 146.
  • In one embodiment, the additional risk assessment is performed in a manner such that the applicable result is returned after at least two risk assessments. In another embodiment, the additional risk assessment is performed one or more times as needed. It should be appreciated that selective actions taken by the risk system 150 according to the post-score rules may be considered consistent with the scope of the present invention. Thus, even if no additional risk assessment if performed based on the initial risk score and the post-score rule, such as the initial risk score being of high risk or of low risk for example, the selective decision process performed by the risk system is consistent with one aspect of the present invention described herein. It should also be appreciated that, based upon the initial risk score and/or the additional risk score, provisional authorization may be provided to the merchant 106 for the purpose of delaying the delivery of services and/or merchandise in a manner as previously described.
  • Once the risk assessment is performed and the score is generated in the state 204, the check approval process advances to the decision state 206. In the decision state 206, the risk system 150 determines the degree of the generated risk score. In one aspect, the risk system 150 may compare the initial risk score with a pre-determined range of a low risk assessment threshold. If the processor 162 determines from the comparison that the financial transaction is of low risk, then the check approval process advances to a state 208 to approve the financial transaction. Subsequently, in a state 210, the check acceptance service 110 notifies the merchant 106 to deliver the vendibles, and then the check approval process terminates in an end state 220. It should be appreciated that the pre-determined range of the low risk assessment threshold may comprise any range of values or parameters set by the merchant 106, the check acceptance service 110, and/or any other guidelines available without departing from the scope of the present invention.
  • Alternatively, in the decision state 206, if the initial risk score fails to fall in the pre-determined range of a low risk assessment threshold, then the check approval process advances to another decision state 212. In the decision state 212, if the risk system 150 compares the initial risk score with a pre-determined range of a marginal risk assessment threshold. If the risk system 150 determines from the comparison that the financial transaction is not of marginal risk, then the check approval process advances to a state 218 to decline the financial transaction. In which case, the check approval process terminates in the end state 220. It should be appreciated that the pre-determined range of the marginal risk assessment threshold may comprise any range of values or parameters set by the merchant 106, the check acceptance service 110, and/or any other guidelines available without departing from the scope of the present invention.
  • Otherwise, if the comparison is determined to comprise a marginal risk assessment score, then the check approval process proceeds to a state 214. In the state 214, the check acceptance service 110 provides the merchant 106 with a provisional authorization in a manner as previously described. As described previously, provisional authorization provides the check acceptance service 110 additional time in a state 214 for further risk assessment, evaluation, and analysis. In the state 254, the risk system 150 performs the provisional authorization process in a manner that will be described in greater detail herein below in reference to FIGS. 4, 5. If, based on the provisional authorization process, approval is authorized in still another decision state 216, then the check approval process advances to the state 208, where the check acceptance service 110 authorizes the financial transaction between the merchant 106 and the customer 100. Then, the merchant 106 is notified by the check acceptance service 110 to deliver the vendibles in the state 210, which is followed by the end state 220. However, if the approval is not granted to the merchant 106 in the decision state 216, then the risk system 150 declines the financial transaction in the state 262, and the check approval process terminates in the end state 264.
  • In an alternative embodiment, the risk system 150 performs an additional risk score assessment after the initial risk score prior to performing the provisional authorization process in the state 214. In still another embodiment, the risk system 150 may perform a plurality of additional risk assessments for the purpose of more accurately assessing the degree of risk of the financial transaction. In addition, multiple risk assessments may be performed, for example, on financial transactions that involve large check draft amounts. It should be appreciated that the risk system 150 may perform any number of additional risk assessments on any number of types of financial transactions without departing from the scope of the present invention.
  • Advantageously, the above-mentioned risk assessment procedure, method, and system represents a significant improvement over traditional check handling procedures that automatically approve or decline borderline or marginal risk assessments. Additionally, the above-mentioned risk assessment method and system utilizes an efficient and selective mechanism for evaluating borderline or marginal exception conditions, such as the provisional authorization process. In one aspect, if borderline exception conditions or marginal risk assessment situations arise, the above-mentioned check acceptance procedure, method, and system selectively delays the delivery of services and/or merchandise prior to authorizing the financial transaction.
  • FIG. 4 illustrates one embodiment of a provisional authorization process that is utilized to evaluate marginal risk assessments. The provisional authorization process, as described herein below, is one embodiment of a functional process flow description of the state 214 in FIG. 3. In one aspect, financial transactions that involve promissory payments and marginal risk assessments may require a period of time for further risk evaluation or the verification of funds prior to the release of services and/or merchandise by the merchant 106. Some merchants 106 may elect to be classified by the check acceptance service 110 as capable of delaying the delivery of services and/or merchandise for the purpose of re-evaluating the marginal risk assessments of borderline risk based customers 100. Sometimes a marginally risky customer 100 may make good on their promissory payments. Therefore, a merchant 106 increases its profitability by accepting some marginally risky financial transactions by utilizing the provisional authorization process.
  • The provisional authorization process initiates in a start state 230, and then advances to a state 232, where the check acceptance service 110 obtains transaction information in a manner as described in the state 202 in FIG. 3. Next, in a state 234, the check acceptance service 110 accesses the merchant 106 record, such as transaction history with the particular customer 100, and determines the merchant's parameters in a manner as described in the state 202 in FIG. 3. Following, in a decision state 236, the check acceptance service 110 determines from the merchant parameters whether the merchant 106 is classified as capable of delaying delivery of services and/or merchandise as previously described in reference to FIGS. 1, 2. Depending on the nature of some businesses, merchants may selectively elect to be classified by the check acceptance agency as either being capable of delaying delivery or not capable of delaying delivery. In addition, the merchant classification may comprise an electronic listing in the internal database 156 or part of the merchant transaction information and/or merchant parameters. Therefore, in the decision state 236, the risk engine 152 may be utilized by the check acceptance service 110 to access the electronic listing in the internal database 156 and perform the determination.
  • If the check acceptance service 110 determines that the merchant 106 is not capable of delaying delivery in the decision state 236, then the provisional authorization process advances to a state 248, where the financial transaction may be declined. Moreover, if the financial transaction is declined in the state 248, the declined results are electronically transferred to the merchant 106 via the interface 146, and the provisional authorization process terminates in an end state 252. It should be appreciated that the merchant 106 may be notified of the applicable results of the financial transaction via the telephone, satellite relay, standard mail, or the internet without departing from the scope of the present invention.
  • Alternatively, if the merchant is capable of delaying delivery in the decision state 236, then the provisional authorization process advances to a state 238, where the check acceptance services 110 provides provisional authorization to the merchant 106 in a manner as previously described, such as electronically via the interface 146 or by telephone. By providing provisional authorization to the merchant 106, the check acceptance service 110 is given a period of time, ranging anywhere from a few minutes to several days, to perform additional risk assessment and evaluation in a state 240.
  • In one aspect, additional risk assessment and evaluation may include verifying the existence of funds in the customer's check issuing bank account in a manner as described in FIG. 1. Furthermore, obtaining additional financial information about the customer in the state 240 may also comprise obtaining information about the customer's recent check writing history and evaluating the customer's recent check writing history to predict whether there will be sufficient funds to cover the cost of the financial transaction. The customer's check writing history may be logged in the internal database 156, the external database 160, and/or saved as a merchant parameter.
  • In one aspect, as described previously, a notification of provisional authorization informs the merchant 106 that additional risk assessment and evaluation is necessary. In this particular situation, the merchant 106 may either delay delivery until the check acceptance service 110 issues a notification of authorization for the financial transaction, or the merchant 106 may elect to deliver the services and/or merchandise after a pre-determined period of time if authorization notification was not issued by the check acceptance service 110 during the pre-determined period of time. It should be appreciated that the pre-determined period of time may include any length of time ranging from a few seconds to a few weeks.
  • Additionally, upon receiving the provisional authorization notification, the merchant 106 knows to delay the delivery of services and/or merchandise until further risk analysis is performed by the check acceptance service 110. It should be appreciated that authorizing delivery after the pre-selected period of time may include agreeing with the merchant 106 that unless the merchant 106 is advised to not deliver the service and/or merchandise at the end of the pre-selected period of time, the delivery of the merchandise is authorized.
  • Moreover, the additional risk assessment and evaluation may require obtaining additional transaction information from the customer 100, such as a driver's license number, a date of birth, a social security number, previous residential addresses, and/or recent check writing history. By obtaining the additional transaction information, the check acceptance service 110 may perform a more in depth risk assessment by generating additional risk scores and accessing more external databases for credit history evaluation, which may result in more successfully avoiding fraud based financial transactions.
  • Once the additional risk assessment and evaluation is performed in the state 240, approval may be determined in another decision state 242. If the check acceptance service 110 approves the financial transaction in the decision sate 242, the financial transaction is authorized in a state 244, and the approval results are transferred to the merchant 106 in the state 250 in a manner as previously described. Next, the provisional authorization process terminates in the end state 252.
  • In some cases, if the financial transaction is not approved in the decision state 242, the check acceptance service 110 may decide to perform more additional processing of the risk assessment. This additional processing may include verifying funds in the customer's bank account or waiting for the check to cleared in a check clearing process in a manner as previously described. If additional processing may be performed, then the processing is performed in the state 240. Otherwise, if additional process may not be performed the financial transaction is declined in the state 248, the applicable results are sent to the merchant 106, and the provisional authorization process terminates in the end state 252.
  • Advantageously, the provisional authorization process may be utilized to increase revenue in financial transactions where marginal risk assessments occur. For example, internet and mail order based merchants may substantially increase profits by integrating the provisional authorization process into practice. In one aspect, customers that order vendibles, such as services and/or merchandise, over the internet often expect to wait for delivery. As a result, the internet is one embodiment of a preferred application of the provisional authorization process, which will be described in greater detail herein below in FIG. 5.
  • FIG. 5 illustrates one example of an application of the provisional authorization process in FIG. 4 to an internet based financial transaction. The internet based provisional authorization process, as described herein below, is one embodiment of a functional process flow description of the state 214 in FIG. 3 and the provisional authorization process in FIG. 4. In one aspect, internet based financial transactions that involve promissory payments, electronic or otherwise, and marginal risk assessments may require a period of time for further risk evaluation or the verification of funds prior to the release and delivery of services and/or merchandise. By nature of the internet business, internet based merchants 106 are usually classified by the check acceptance service 110 as capable of delaying the delivery of services and/or merchandise. For the purpose of re-evaluating marginal risk assessments of borderline risk based customers 100, the typical internet based merchant 106 may substantially increase profitability by accepting some marginally risky financial transactions via the utilization of the provisional authorization process as described in FIG. 4.
  • The internet based provisional authorization process initiates in a start state 260. In a state 262, the check acceptance service 110 electronically obtains transaction information from the customer 100 via the merchant's web page or an email attachment. For privacy reasons, sometimes a customer 100 may choose to submit transaction information via the telephone. Next, in a state 264, the check acceptance service 110 electronically obtains the merchant record and parameters from the internal database 156. The check acceptance service 110 determines in a decision state 266 that delivery of vendibles 106 may be delayed. In this particular embodiment, the check acceptance service 110 previously determined that the internet based financial transaction is marginally risky by utilizing the check approval process in FIG. 3. It should be appreciated that a low risk assessment results in approval, and a high risk assessment results in a decline.
  • As a result of determining a delayed delivery in the decision state 266, the check acceptance service 110 provides provisional authorization to the merchant 106 in a state 268, which notifies the merchant 106 to delay delivery of the vendibles 106 until funds in the customer's banking account are verified in a state 270. In this particular embodiment, the check acceptance service 110 seeks funds through the automatic clearing house (ACH) as previously described in FIG. 1. In another embodiment, the check acceptance service 110 may contact via the telephone the customer's check issuing bank 116 to verify funds in the customer's banking account.
  • If the funds are determined available in another decision state 272, then the internet based financial transaction is approved in a state 274, the merchant 106 is notified via telephone, email, or otherwise to deliver the vendibles 106 to the customer 100, and the internet based provisional authorization process terminates in an end state 282. Otherwise, in the decision state 272, if the funds are not available in the customer's banking account, then the financial transaction is declined in a state 278, and the merchant 106 is notified via telephone, email, or otherwise to cancel the delivery of the vendibles 106 to the customer 100 in a state 280. Following the state 280, the internet based provisional authorization process terminates in the end state 282.
  • Advantageously, the above-mentioned risk assessment procedure, method, and system represents a significant improvement over traditional check handling procedures that automatically approve or decline marginally risky financial transactions or require the transfer of a paper check among various financial institutions. For example, the above-mentioned risk assessment method and system utilizes an efficient and selective mechanism for evaluating borderline exception conditions and marginal risk assessments, such as utilizing the provisional authorization process in borderline risk transactions with marginal risk scores. In one aspect, if marginal risk assessment situations arise, the above-mentioned check acceptance procedure, method, and system selectively delays the delivery of services and/or merchandise prior to authorizing the financial transaction in a manner such that the customer is marginally inconvenienced, the merchant retains the vendibles, and the check acceptance service reduces the potential loss of funds.
  • Although the following description exemplifies one embodiment of the present invention, it should be understood that various omissions, substitutions, and changes in the form of the detail of the apparatus, system, and/or method as illustrated as well as the uses thereof, may be made by those skilled in the art, without departing from the spirit of the present invention. Consequently, the scope of the present invention should not be limited to the disclosed embodiments, but should be defined by the appended claims.

Claims (19)

1. A method of approving a financial transaction between a customer and a merchant, wherein a customer payment is exchanged for merchant vendibles, the method comprising:
performing, with a computer, a risk assessment of a financial transaction between a customer and a merchant, wherein a customer payment is exchanged for merchant vendibles, and wherein the risk assessment generates a risk score based at least in part on transaction information associated with the financial transaction;
provisionally authorizing the financial transaction based at least in part on the risk score;
delaying delivery of the merchant vendibles for a period of time when the financial transaction is provisionally authorized;
electronically obtaining additional transaction information related to the financial transaction between the customer and the merchant during the period of time associated with delaying delivery of the merchant vendibles; and
authorizing delivery of the merchant vendibles, with a computer, based at least in part on the additional transaction information obtained during the period of time associated with delaying delivery of the merchant vendibles.
2. The method of claim 1, wherein approving the financial transaction comprises a mail order based financial transaction.
3. The method of claim 1, wherein authorizing delivery comprises contacting the merchant and advising the merchant to deliver the vendibles to the customer.
4. The method of claim 1, wherein authorizing delivery comprises agreeing with the merchant that unless the merchant is advised to not ship at the end of the period of time, the delivery of the vendibles is authorized.
5. The method of claim 1, wherein the period of time ranges from at least one micro-second to a few weeks.
6. The method of claim 1, wherein obtaining additional transaction information comprises verifying availability of funds in a checking account belonging to the customer to cover the cost of the financial transaction.
7. The method of claim 1, wherein obtaining additional transaction information comprises obtaining information about the customer's recent check writing history and evaluating the customer's recent check writing history to predict whether there will be sufficient funds to cover the cost of the financial transaction.
8. The method claim 1, wherein the financial transaction comprises exchanging a promissory payment.
9. The method claim 1, wherein the financial transaction comprises exchanging an electronic payment.
10. A system of approving a financial transaction between a customer and a merchant, wherein a customer payment is exchanged for merchant vendibles, the system comprising:
a risk engine executable in a computer that is configured to perform a risk assessment of a financial transaction between a customer and a merchant, wherein a customer payment is exchanged for merchant vendibles, wherein the risk engine generates a risk score based at least in part on transaction information associated with the financial transaction, and wherein the risk engine is further configured to provisionally authorize the transaction based at least in part on the risk score;
a delivery delay module executable in a computer that is configured to delay the delivery of the merchant vendibles for a period of time when the financial transaction is provisionally authorized, wherein additional information related to the financial transaction between the customer and the merchant is obtained during the period of time associated with the delay of delivery of the merchant vendibles; and
an authorization module executable in a computer that is configured to authorize delivery of the merchant vendibles based at least in part on the additional transaction information obtained during the period of time associated with the delay of the delivery of the merchant vendibles.
11. The system of claim 10, wherein the authorization module further comprises a communications device that contacts the merchant via a communications medium and advises the merchant to deliver the vendibles to the customer if the financial transaction can be classified as low risk.
12. The system of claim 10, wherein the authorization module authorizes the delivery of the vendibles after the period of time unless the merchant is advised to not ship at the end of the period of time by the authorization module.
13. The system of claim 10, wherein the risk engine is further configured to determine if the merchant is a merchant who can delay delivery of the vendibles.
14. The system of claim 10, wherein the period of time ranges from at least one micro-second to a few weeks.
15. The system of claim 10, wherein the additional transaction information verifies the availability of funds in a checking account belonging to the customer to cover the cost of the financial transaction.
16. The system of claim 10, wherein the additional transaction information comprises transaction information about the customer's recent check writing history.
17. The system of claim 16, wherein the risk engine is further configured to evaluate the customer's recent check writing history to predict whether there will be sufficient funds to cover the cost of the financial transaction.
18. The system claim 10, wherein the customer payment comprises an electronic payment.
19. The system claim 10, wherein the customer payment comprises a check.
US11/832,505 2002-01-07 2007-08-01 Systems and methods for selectively delaying financial transactions Abandoned US20080021803A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US11/832,505 US20080021803A1 (en) 2002-01-07 2007-08-01 Systems and methods for selectively delaying financial transactions

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/041,954 US7346575B1 (en) 2002-01-07 2002-01-07 Systems and methods for selectively delaying financial transactions
US11/832,505 US20080021803A1 (en) 2002-01-07 2007-08-01 Systems and methods for selectively delaying financial transactions

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US10/041,954 Continuation US7346575B1 (en) 2002-01-07 2002-01-07 Systems and methods for selectively delaying financial transactions

Publications (1)

Publication Number Publication Date
US20080021803A1 true US20080021803A1 (en) 2008-01-24

Family

ID=38972567

Family Applications (2)

Application Number Title Priority Date Filing Date
US10/041,954 Active 2025-12-22 US7346575B1 (en) 2002-01-07 2002-01-07 Systems and methods for selectively delaying financial transactions
US11/832,505 Abandoned US20080021803A1 (en) 2002-01-07 2007-08-01 Systems and methods for selectively delaying financial transactions

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US10/041,954 Active 2025-12-22 US7346575B1 (en) 2002-01-07 2002-01-07 Systems and methods for selectively delaying financial transactions

Country Status (1)

Country Link
US (2) US7346575B1 (en)

Cited By (60)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050245308A1 (en) * 2004-04-29 2005-11-03 Cfph, Llc System and method for wagering based on financial market indicators
US20080114657A1 (en) * 2002-11-01 2008-05-15 Modasolutions Corporation Internet payment system and method
US20090030763A1 (en) * 2007-07-18 2009-01-29 Purtell Daniel J Supplier compliance manager tool
US20090132409A1 (en) * 2007-11-15 2009-05-21 Lutnick Howard W Trading system products and processes
US20090163266A1 (en) * 2007-12-21 2009-06-25 Amaitis Lee M System and method for slot machine game associated with market line wagers
US20090240624A1 (en) * 2008-03-20 2009-09-24 Modasolutions Corporation Risk detection and assessment of cash payment for electronic purchase transactions
US20090248465A1 (en) * 2008-03-28 2009-10-01 Fortent Americas Inc. Assessment of risk associated with doing business with a party
US20090248560A1 (en) * 2008-03-28 2009-10-01 Fortent Americas Inc. Assessment of risk associated with doing business with a party
US20090248559A1 (en) * 2008-03-28 2009-10-01 Fortent Americas Inc. Assessment of risk associated with doing business with a party
US20090307121A1 (en) * 2008-06-09 2009-12-10 Lutnick Howard W Trading system products and processes
US20090313169A1 (en) * 2006-05-13 2009-12-17 Kevin Foley Products and processes for utilizing order data and related data
US20100057626A1 (en) * 2008-09-04 2010-03-04 Lutnick Howard W Cancellation timing in an electronic marketplace
AU2009101005B4 (en) * 2009-09-30 2010-03-04 Lidolo Pty Ltd Systems and methods for processing transaction data
US20100057627A1 (en) * 2008-09-04 2010-03-04 Lutnick Howard W Non-firm orders in electronic marketplaces
US20100076884A1 (en) * 2008-09-25 2010-03-25 Lutnick Howard W Trading related to fund compositions
US20100076896A1 (en) * 2008-09-25 2010-03-25 Lutnick Howard W Substitutability of financial instruments
US20100076883A1 (en) * 2008-09-25 2010-03-25 Lutnick Howard W Generating risk pools
US20100082495A1 (en) * 2008-09-28 2010-04-01 Lutnick Howard W Trading system accessibility
US20100082500A1 (en) * 2008-09-28 2010-04-01 Lutnick Howard W Interaction with trading systems
US20100106636A1 (en) * 2008-10-24 2010-04-29 Lutnick Howard W Interprogram communication using messages related to order cancellation
US20100191638A1 (en) * 2009-01-23 2010-07-29 Alderucci Dean P Multicomputer distributed processing of data related to automation of trading
US20100191637A1 (en) * 2009-01-23 2010-07-29 Alderucci Dean P Interprogram communication using messages related to groups of orders
WO2010085746A1 (en) * 2009-01-23 2010-07-29 Cfph, Llc Multicomputer distributed processing techniques to prevent information leakage
US20100280880A1 (en) * 2009-05-04 2010-11-04 Patrick Faith Determining targeted incentives based on consumer transaction history
US20100332368A1 (en) * 2009-06-30 2010-12-30 Alderucci Dean P Multicomputer distributed processing of data regarding trading opportunities
US20110060686A1 (en) * 2009-09-10 2011-03-10 Kenneth Gay System and Method for Communicating Check Information to a Financial Institution
WO2011038462A1 (en) * 2009-09-30 2011-04-07 Lidolo Pty Ltd Systems and methods for processing transactional data
US8460085B2 (en) 2007-12-21 2013-06-11 Cfph, Llc System and method for providing a roulette game based on financial market indicators
US8535140B2 (en) 2007-12-21 2013-09-17 Cfph, Llc System and method for providing a baccarat game based on financial market indicators
US20130275176A1 (en) * 2012-04-16 2013-10-17 Bank Of America Corporation Risk assessment of a supplier of an organization
US8583492B2 (en) * 2010-07-16 2013-11-12 Bank Of America Corporation Check processing and funds verification
US20140006267A1 (en) * 2010-09-24 2014-01-02 Ethoca Technologies, Inc. Stakeholder collaboration
US8645272B2 (en) 2011-06-24 2014-02-04 Western Union Financial Services, Inc. System and method for loading stored value accounts
US8684814B2 (en) 2007-12-21 2014-04-01 Cfph, Llc System and method for slot machine game associated with financial market indicators
US8688477B1 (en) 2010-09-17 2014-04-01 National Assoc. Of Boards Of Pharmacy Method, system, and computer program product for determining a narcotics use indicator
US9230407B2 (en) 2004-04-29 2016-01-05 Cfph, Llc System and method for wagering based on multiple financial market indicators
US9293009B2 (en) 2004-04-29 2016-03-22 Cfph, Llc System and method for mapping results from sporting events to game inputs
US20170221167A1 (en) * 2016-01-28 2017-08-03 Bank Of America Corporation System and Network for Detecting Unauthorized Activity
US20180096428A1 (en) * 2016-09-30 2018-04-05 Mastercard International Incorporated Methods, systems, and networks, for proactive currency exchange
US9974512B2 (en) 2014-03-13 2018-05-22 Convergence Medical, Llc Method, system, and computer program product for determining a patient radiation and diagnostic study score
US20180285836A1 (en) * 2015-09-23 2018-10-04 Mroute Corp. System and method for settling multiple payees from a single electronic and/or check payment
US10122889B1 (en) 2017-05-08 2018-11-06 Bank Of America Corporation Device for generating a resource distribution document with physical authentication markers
US10121199B1 (en) 2017-06-23 2018-11-06 Cfph, Llc Distributed trading network and interface
US10129126B2 (en) 2016-06-08 2018-11-13 Bank Of America Corporation System for predictive usage of resources
US10178101B2 (en) 2016-06-08 2019-01-08 Bank Of America Corporation System for creation of alternative path to resource acquisition
US10178111B1 (en) * 2015-09-24 2019-01-08 Equifax Inc. Providing compressed risk assessment messages for real-time transmission via data networks to online services
US10291487B2 (en) 2016-06-08 2019-05-14 Bank Of America Corporation System for predictive acquisition and use of resources
US10296911B2 (en) 2013-10-01 2019-05-21 Ethoca Technologies, Inc. Systems and methods for rescuing purchase transactions
US10373144B1 (en) 2015-05-13 2019-08-06 Square, Inc. Transaction payment processing by multiple data centers
US10402807B1 (en) * 2017-02-28 2019-09-03 Square, Inc. Estimating interchange fees for card payments
US10433196B2 (en) 2016-06-08 2019-10-01 Bank Of America Corporation System for tracking resource allocation/usage
US10581988B2 (en) 2016-06-08 2020-03-03 Bank Of America Corporation System for predictive use of resources
US10621363B2 (en) 2017-06-13 2020-04-14 Bank Of America Corporation Layering system for resource distribution document authentication
US10977624B2 (en) 2017-04-12 2021-04-13 Bank Of America Corporation System for generating paper and digital resource distribution documents with multi-level secure authorization requirements
US20210224760A1 (en) * 2015-08-20 2021-07-22 Petr SOBOTKA Transfer of digital currency encryption keys through the process of issuance, validation and devaluation of physical medium with multi-factor authorization, and the physical medium of encryption keys for digital currency to conduct this transfer technology
US11257330B2 (en) 2008-02-15 2022-02-22 Cfph, Llc System and method for providing a baccarat game based on financial market indicators
CN114666248A (en) * 2022-05-18 2022-06-24 浙商银行股份有限公司 Allocation chain fragmentation transaction distribution method and device
US20220294821A1 (en) * 2019-08-22 2022-09-15 Shanghai Bilibili Technology Co., Ltd. Risk control method, computer device, and readable storage medium
US20220292524A1 (en) * 2021-03-10 2022-09-15 International Business Machines Corporation System and method to monitor relevance of customer's business risk due to market changes
US11627134B1 (en) * 2019-09-12 2023-04-11 Amazon Technologies, Inc. Cancellation and reversion of unauthorized operations

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050165699A1 (en) * 1996-11-12 2005-07-28 Hahn-Carlson Dean W. Processing and management of transaction timing characteristics
US20070055582A1 (en) 1996-11-12 2007-03-08 Hahn-Carlson Dean W Transaction processing with core and distributor processor implementations
US20080172314A1 (en) 1996-11-12 2008-07-17 Hahn-Carlson Dean W Financial institution-based transaction processing system and approach
US8392285B2 (en) 1996-11-12 2013-03-05 Syncada Llc Multi-supplier transaction and payment programmed processing approach with at least one supplier
US8396811B1 (en) 1999-02-26 2013-03-12 Syncada Llc Validation approach for auditing a vendor-based transaction
US7283977B1 (en) * 2000-02-25 2007-10-16 Kathleen Tyson-Quah System for reducing risk payment-based transactions wherein a risk filter routine returns instructions authorizing payment to a payment queue for later re-evaluation
US20040199462A1 (en) * 2003-04-02 2004-10-07 Ed Starrs Fraud control method and system for network transactions
AU2005255456B2 (en) 2004-06-09 2007-09-13 Syncada Llc Order-resource fulfillment and management system and approach
US8762238B2 (en) 2004-06-09 2014-06-24 Syncada Llc Recurring transaction processing system and approach
MXPA06014352A (en) * 2004-06-09 2007-07-25 Bancorp Licensing Inc Transaction processing with core and distributor processor implementations.
US7970671B2 (en) * 2005-04-12 2011-06-28 Syncada Llc Automated transaction processing system and approach with currency conversion
US20080015977A1 (en) * 2006-06-14 2008-01-17 Curry Edith L Methods of deterring fraud and other improper behaviors within an organization
US8285636B2 (en) * 2006-06-14 2012-10-09 Curry Edith L Methods of monitoring behavior/activity of an individual associated with an organization
US8712884B2 (en) 2006-10-06 2014-04-29 Syncada Llc Transaction finance processing system and approach
US7925581B2 (en) * 2007-02-21 2011-04-12 Mordecai David K A System and method for dynamic path- and state-dependent stochastic control allocation
US8185457B1 (en) 2007-10-25 2012-05-22 United Services Automobile Association (Usaa) Transaction risk analyzer
US8751337B2 (en) 2008-01-25 2014-06-10 Syncada Llc Inventory-based payment processing system and approach
US20110191238A1 (en) * 2010-01-29 2011-08-04 Bank Of America Corporation Variable merchant settlement options
US20130031001A1 (en) * 2011-07-26 2013-01-31 Stephen Patrick Frechette Method and System for the Location-Based Discovery and Validated Payment of a Service Provider
CN108492104B (en) 2018-02-12 2020-10-02 阿里巴巴集团控股有限公司 Resource transfer monitoring method and device
US11363106B2 (en) 2020-05-26 2022-06-14 Bank Of America Corporation Electronic system for combination of temporal resource activity data and resource transmission

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5175682A (en) * 1990-12-14 1992-12-29 Verifone, Inc. Check system and method including prioritizing checks for transmission to banks for processing
US5444616A (en) * 1992-10-30 1995-08-22 Microbilt Corporation Financial transaction systems and methods utilizing a multi-reader transaction terminal
US5679940A (en) * 1994-12-02 1997-10-21 Telecheck International, Inc. Transaction system with on/off line risk assessment
US5848412A (en) * 1996-11-19 1998-12-08 Ncr Corporation User controlled browser identification disclosing mechanism
US5930777A (en) * 1997-04-15 1999-07-27 Barber; Timothy P. Method of charging for pay-per-access information over a network
US5991758A (en) * 1997-06-06 1999-11-23 Madison Information Technologies, Inc. System and method for indexing information about entities from different information sources
US6097834A (en) * 1997-06-13 2000-08-01 Paystation America Inc. Financial transaction processing systems and methods
US6117011A (en) * 1995-07-27 2000-09-12 Lvov; Denis Ernestovich Electronic game system, method of managing and regulating said system
US6260024B1 (en) * 1998-12-02 2001-07-10 Gary Shkedy Method and apparatus for facilitating buyer-driven purchase orders on a commercial network system

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5175682A (en) * 1990-12-14 1992-12-29 Verifone, Inc. Check system and method including prioritizing checks for transmission to banks for processing
US5444616A (en) * 1992-10-30 1995-08-22 Microbilt Corporation Financial transaction systems and methods utilizing a multi-reader transaction terminal
US5679940A (en) * 1994-12-02 1997-10-21 Telecheck International, Inc. Transaction system with on/off line risk assessment
US6117011A (en) * 1995-07-27 2000-09-12 Lvov; Denis Ernestovich Electronic game system, method of managing and regulating said system
US5848412A (en) * 1996-11-19 1998-12-08 Ncr Corporation User controlled browser identification disclosing mechanism
US5930777A (en) * 1997-04-15 1999-07-27 Barber; Timothy P. Method of charging for pay-per-access information over a network
US5991758A (en) * 1997-06-06 1999-11-23 Madison Information Technologies, Inc. System and method for indexing information about entities from different information sources
US6097834A (en) * 1997-06-13 2000-08-01 Paystation America Inc. Financial transaction processing systems and methods
US6260024B1 (en) * 1998-12-02 2001-07-10 Gary Shkedy Method and apparatus for facilitating buyer-driven purchase orders on a commercial network system

Cited By (107)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9275410B2 (en) 2002-11-01 2016-03-01 Western Union Financial Services, Inc. Internet payment system and method
US20080114657A1 (en) * 2002-11-01 2008-05-15 Modasolutions Corporation Internet payment system and method
US8566237B2 (en) 2002-11-01 2013-10-22 Western Union Financial Services, Inc. Internet payment system and method
US9293009B2 (en) 2004-04-29 2016-03-22 Cfph, Llc System and method for mapping results from sporting events to game inputs
US9230407B2 (en) 2004-04-29 2016-01-05 Cfph, Llc System and method for wagering based on multiple financial market indicators
US8968078B2 (en) 2004-04-29 2015-03-03 Cfph, Llc Amusement devices and chance devices based on financial market indicators
US10977904B2 (en) 2004-04-29 2021-04-13 Cfph, Llc System and method for wagering based on multiple financial market indicators
US10360764B2 (en) 2004-04-29 2019-07-23 Cfph, Llc System and method for mapping results from sporting events to game inputs
US20050245308A1 (en) * 2004-04-29 2005-11-03 Cfph, Llc System and method for wagering based on financial market indicators
US11308762B2 (en) 2004-04-29 2022-04-19 Cfph, Llc System and method for mapping results from sporting events to game inputs
US10249149B2 (en) 2004-04-29 2019-04-02 Cfph, Llc System and method for wagering based on multiple financial market indicators
US9355527B2 (en) 2004-04-29 2016-05-31 Cfph, Llc Amusement devices and chance devices based on financial market indicators
US9064256B2 (en) 2006-05-13 2015-06-23 Cfph, Llc Products and processes for utilizing order data and related data
US20090313169A1 (en) * 2006-05-13 2009-12-17 Kevin Foley Products and processes for utilizing order data and related data
US20090030763A1 (en) * 2007-07-18 2009-01-29 Purtell Daniel J Supplier compliance manager tool
US10262366B2 (en) 2007-11-15 2019-04-16 Cfph, Llc Trading system products and processes
US20090132409A1 (en) * 2007-11-15 2009-05-21 Lutnick Howard W Trading system products and processes
US8285629B2 (en) 2007-11-15 2012-10-09 Cfph, Llc Trading system products and processes
US10636091B2 (en) 2007-11-15 2020-04-28 Cfph, Llc Trading system products and processes
US11023971B2 (en) 2007-11-15 2021-06-01 Cfph, Llc Large block trading
US8768819B2 (en) 2007-11-15 2014-07-01 Cfph, Llc Multicomputer distributed processing of large block trading data
US20090204535A1 (en) * 2007-11-15 2009-08-13 Lutnick Howard W Large block trading
US10332332B2 (en) 2007-12-21 2019-06-25 Cfph, Llc System and method for slot machine game associated with financial market indicators
US8535140B2 (en) 2007-12-21 2013-09-17 Cfph, Llc System and method for providing a baccarat game based on financial market indicators
US20090163266A1 (en) * 2007-12-21 2009-06-25 Amaitis Lee M System and method for slot machine game associated with market line wagers
US10290187B2 (en) 2007-12-21 2019-05-14 Cfph, Llc System and method for providing a baccarat game based on financial market indicators
US9293004B2 (en) 2007-12-21 2016-03-22 Cfph, Llc System and method for providing a roulette game
US11049369B2 (en) 2007-12-21 2021-06-29 Cfph, Llc System and method for slot machine game associated with market line wagers
US10332356B2 (en) 2007-12-21 2019-06-25 Cfph, Llc System and method for providing a roulette game based on multiple financial market indicators
US11024112B2 (en) 2007-12-21 2021-06-01 Cfph, Llc System and method for slot machine game associated with financial market indicators
US8758108B2 (en) 2007-12-21 2014-06-24 Cfph, Llc System and method for slot machine game associated with market line wagers
US10482721B2 (en) 2007-12-21 2019-11-19 Cfph, Llc System and method for slot machine game associated with market line wagers
US9536395B2 (en) 2007-12-21 2017-01-03 Cfph, Llc System and method for providing a baccarat game based on financial market indicators
US10593160B2 (en) 2007-12-21 2020-03-17 Cfph, Llc System and method for providing a baccarat game based on financial market indicators
US8460085B2 (en) 2007-12-21 2013-06-11 Cfph, Llc System and method for providing a roulette game based on financial market indicators
US8684814B2 (en) 2007-12-21 2014-04-01 Cfph, Llc System and method for slot machine game associated with financial market indicators
US9799171B2 (en) 2007-12-21 2017-10-24 Cfph, Llc Techniques for providing a roulette game
US11257330B2 (en) 2008-02-15 2022-02-22 Cfph, Llc System and method for providing a baccarat game based on financial market indicators
US20090240624A1 (en) * 2008-03-20 2009-09-24 Modasolutions Corporation Risk detection and assessment of cash payment for electronic purchase transactions
US20090248560A1 (en) * 2008-03-28 2009-10-01 Fortent Americas Inc. Assessment of risk associated with doing business with a party
US20090248559A1 (en) * 2008-03-28 2009-10-01 Fortent Americas Inc. Assessment of risk associated with doing business with a party
US20090248465A1 (en) * 2008-03-28 2009-10-01 Fortent Americas Inc. Assessment of risk associated with doing business with a party
US20090307121A1 (en) * 2008-06-09 2009-12-10 Lutnick Howard W Trading system products and processes
US20100057626A1 (en) * 2008-09-04 2010-03-04 Lutnick Howard W Cancellation timing in an electronic marketplace
US20100057627A1 (en) * 2008-09-04 2010-03-04 Lutnick Howard W Non-firm orders in electronic marketplaces
US8712903B2 (en) 2008-09-25 2014-04-29 Cfph, Llc Trading related to fund compositions
US20100076883A1 (en) * 2008-09-25 2010-03-25 Lutnick Howard W Generating risk pools
US20100076896A1 (en) * 2008-09-25 2010-03-25 Lutnick Howard W Substitutability of financial instruments
US11068983B2 (en) 2008-09-25 2021-07-20 Cfph, Llc Method and system for order management
US20100076884A1 (en) * 2008-09-25 2010-03-25 Lutnick Howard W Trading related to fund compositions
US20100082500A1 (en) * 2008-09-28 2010-04-01 Lutnick Howard W Interaction with trading systems
US20100082495A1 (en) * 2008-09-28 2010-04-01 Lutnick Howard W Trading system accessibility
US20100106636A1 (en) * 2008-10-24 2010-04-29 Lutnick Howard W Interprogram communication using messages related to order cancellation
US8560431B2 (en) * 2008-10-24 2013-10-15 Cfph, Llc Order cancellation
US8321323B2 (en) 2008-10-24 2012-11-27 Cfph, Llc Interprogram communication using messages related to order cancellation
US10817939B2 (en) * 2009-01-23 2020-10-27 Cfph, Llc Interprogram communication using messages related to groups of orders
US8977565B2 (en) 2009-01-23 2015-03-10 Cfph, Llc Interprogram communication using messages related to groups of orders
US20150310549A1 (en) * 2009-01-23 2015-10-29 Cfph, Llc Interprogram communication using messages related to groups of orders
WO2010085746A1 (en) * 2009-01-23 2010-07-29 Cfph, Llc Multicomputer distributed processing techniques to prevent information leakage
US20100191637A1 (en) * 2009-01-23 2010-07-29 Alderucci Dean P Interprogram communication using messages related to groups of orders
US20100191638A1 (en) * 2009-01-23 2010-07-29 Alderucci Dean P Multicomputer distributed processing of data related to automation of trading
US20100280882A1 (en) * 2009-05-04 2010-11-04 Patrick Faith Frequency-based transaction prediction and processing
US9773246B2 (en) 2009-05-04 2017-09-26 Visa International Service Association Pre-authorization of a transaction using predictive modeling
US9727868B2 (en) 2009-05-04 2017-08-08 Visa International Service Association Determining targeted incentives based on consumer transaction history
US9984379B2 (en) 2009-05-04 2018-05-29 Visa International Service Association Determining targeted incentives based on consumer transaction history
US20100280880A1 (en) * 2009-05-04 2010-11-04 Patrick Faith Determining targeted incentives based on consumer transaction history
US8352315B2 (en) 2009-05-04 2013-01-08 Visa International Service Association Pre-authorization of a transaction using predictive modeling
US20100280927A1 (en) * 2009-05-04 2010-11-04 Patrick Faith Pre-authorization of a transaction using predictive modeling
US9489674B2 (en) 2009-05-04 2016-11-08 Visa International Service Association Frequency-based transaction prediction and processing
US20100280881A1 (en) * 2009-05-04 2010-11-04 Patrick Faith Demographic analysis using time-based consumer transaction histories
US20100332368A1 (en) * 2009-06-30 2010-12-30 Alderucci Dean P Multicomputer distributed processing of data regarding trading opportunities
US20110060686A1 (en) * 2009-09-10 2011-03-10 Kenneth Gay System and Method for Communicating Check Information to a Financial Institution
WO2011038462A1 (en) * 2009-09-30 2011-04-07 Lidolo Pty Ltd Systems and methods for processing transactional data
AU2009101005B4 (en) * 2009-09-30 2010-03-04 Lidolo Pty Ltd Systems and methods for processing transaction data
US8583492B2 (en) * 2010-07-16 2013-11-12 Bank Of America Corporation Check processing and funds verification
US8688477B1 (en) 2010-09-17 2014-04-01 National Assoc. Of Boards Of Pharmacy Method, system, and computer program product for determining a narcotics use indicator
US20140006267A1 (en) * 2010-09-24 2014-01-02 Ethoca Technologies, Inc. Stakeholder collaboration
US8645272B2 (en) 2011-06-24 2014-02-04 Western Union Financial Services, Inc. System and method for loading stored value accounts
US20130275176A1 (en) * 2012-04-16 2013-10-17 Bank Of America Corporation Risk assessment of a supplier of an organization
US10296911B2 (en) 2013-10-01 2019-05-21 Ethoca Technologies, Inc. Systems and methods for rescuing purchase transactions
US11301858B2 (en) 2013-10-01 2022-04-12 Ethoca Technologies, Inc. Systems and methods for rescuing purchase transactions
US11375971B2 (en) 2014-03-13 2022-07-05 Clinicentric, Llc Method, system, and computer program product for determining a patient radiation and diagnostic study score
US9974512B2 (en) 2014-03-13 2018-05-22 Convergence Medical, Llc Method, system, and computer program product for determining a patient radiation and diagnostic study score
US10373144B1 (en) 2015-05-13 2019-08-06 Square, Inc. Transaction payment processing by multiple data centers
US20210224760A1 (en) * 2015-08-20 2021-07-22 Petr SOBOTKA Transfer of digital currency encryption keys through the process of issuance, validation and devaluation of physical medium with multi-factor authorization, and the physical medium of encryption keys for digital currency to conduct this transfer technology
US20180285836A1 (en) * 2015-09-23 2018-10-04 Mroute Corp. System and method for settling multiple payees from a single electronic and/or check payment
US10853771B2 (en) * 2015-09-23 2020-12-01 Mroute Corp. System and method for settling multiple payees from a single electronic and/or check payment
US10178111B1 (en) * 2015-09-24 2019-01-08 Equifax Inc. Providing compressed risk assessment messages for real-time transmission via data networks to online services
US20170221167A1 (en) * 2016-01-28 2017-08-03 Bank Of America Corporation System and Network for Detecting Unauthorized Activity
US10178101B2 (en) 2016-06-08 2019-01-08 Bank Of America Corporation System for creation of alternative path to resource acquisition
US11412054B2 (en) 2016-06-08 2022-08-09 Bank Of America Corporation System for predictive use of resources
US10129126B2 (en) 2016-06-08 2018-11-13 Bank Of America Corporation System for predictive usage of resources
US10291487B2 (en) 2016-06-08 2019-05-14 Bank Of America Corporation System for predictive acquisition and use of resources
US10581988B2 (en) 2016-06-08 2020-03-03 Bank Of America Corporation System for predictive use of resources
US10433196B2 (en) 2016-06-08 2019-10-01 Bank Of America Corporation System for tracking resource allocation/usage
US20180096428A1 (en) * 2016-09-30 2018-04-05 Mastercard International Incorporated Methods, systems, and networks, for proactive currency exchange
US10402807B1 (en) * 2017-02-28 2019-09-03 Square, Inc. Estimating interchange fees for card payments
US10977624B2 (en) 2017-04-12 2021-04-13 Bank Of America Corporation System for generating paper and digital resource distribution documents with multi-level secure authorization requirements
US10122889B1 (en) 2017-05-08 2018-11-06 Bank Of America Corporation Device for generating a resource distribution document with physical authentication markers
US10621363B2 (en) 2017-06-13 2020-04-14 Bank Of America Corporation Layering system for resource distribution document authentication
US10121199B1 (en) 2017-06-23 2018-11-06 Cfph, Llc Distributed trading network and interface
US10922752B2 (en) 2017-06-23 2021-02-16 Cfph, Llc Distributed trading network and interface
US11625778B2 (en) 2017-06-23 2023-04-11 Cfph, Llc Distributed trading network and interface
US20220294821A1 (en) * 2019-08-22 2022-09-15 Shanghai Bilibili Technology Co., Ltd. Risk control method, computer device, and readable storage medium
US11627134B1 (en) * 2019-09-12 2023-04-11 Amazon Technologies, Inc. Cancellation and reversion of unauthorized operations
US20220292524A1 (en) * 2021-03-10 2022-09-15 International Business Machines Corporation System and method to monitor relevance of customer's business risk due to market changes
CN114666248A (en) * 2022-05-18 2022-06-24 浙商银行股份有限公司 Allocation chain fragmentation transaction distribution method and device

Also Published As

Publication number Publication date
US7346575B1 (en) 2008-03-18

Similar Documents

Publication Publication Date Title
US7346575B1 (en) Systems and methods for selectively delaying financial transactions
US20050080716A1 (en) Data validation systems and methods for use in financial transactions
US20050080717A1 (en) Data validation systems and methods for financial transactions
US11107070B1 (en) Payment vehicle with on and off function
US7668776B1 (en) Systems and methods for selective use of risk models to predict financial risk
US7627525B2 (en) Automated check cashing and loan processing ATM system and methodology
US6757664B1 (en) Method and system for verification of checks at a point of sale
US8504470B1 (en) Methods and systems for financial transactions
US6647376B1 (en) System and method for point-of-sale check authorization
US8666886B2 (en) System, program product, and method for debit card and checking account autodraw
US7513418B2 (en) Systems and methods for performing a simplified risk assessment
US8104678B2 (en) Payment approval system and method for approving payment for credit card
US7251624B1 (en) Score based decisioning
US7392942B2 (en) Systems and methods for electronic transaction risk processing
US8266057B2 (en) Methods and systems for assigning interchange rates to financial transactions using an interchange network
US20060229961A1 (en) Risk evaluation method and system using ACH data
US20130253956A1 (en) Chargeback insurance
US20090327107A1 (en) Consumer spending threshold evaluation
US20070299775A1 (en) Systems and methods for associating a second source of funds with an electronic check transaction
US8688548B2 (en) Negative balance management
WO2010044288A1 (en) Settlement and authorization system for credit card
US20070095894A1 (en) Alternative banking system for managing traditional and nontraditional markets
US7970673B2 (en) Method, apparatus, and computer program product for repository data maximization
US20040030644A1 (en) Systems for facilitating card processing systems/improved risk control
US20240037560A1 (en) Systems and Methods for Dynamic Authorization of Virtual Bank Account Transactions

Legal Events

Date Code Title Description
STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION