(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2004/0230527 A1
`(43) Pub. Date:
`Nov. 18, 2004
`Hansen et al.
`
`US 20040230527A1
`
`(54) AUTHENTICATION FOR ONLINE MONEY
`TRANSFERS
`
`(75) Inventors: Scott Hansen, Woodcliff Lake, NJ
`(US); Kirsten S. Fry-Sanchez,
`Evergreen, CO (US); Kim C. Hosmer,
`Castle Rock, CO (US); Ed N. Cortez,
`Denver, CO (US); Debra Joyner,
`Littleton, CO (US); Jennifer Wieth,
`Golden, CO (US); Mark D. Baumgart,
`Larkspur, CO (US)
`Correspondence Address:
`TOWNSEND AND TOWNSEND AND CREW,
`LLP
`TWO EMBARCADERO CENTER
`EIGHTH FLOOR
`SAN FRANCISCO, CA 94111-3834 (US)
`(73) Assignee: First Data Corporation, Englewood,
`CO
`
`(21)
`(22)
`
`Appl. No.:
`Filed:
`
`10/832.809
`Apr. 26, 2004
`Related U.S. Application Data
`(60) Provisional application No. 60/466,871, filed on Apr.
`29, 2003.
`
`Publication Classification
`
`(51) Int. Cl." ..................................................... G06F 17/60
`(52) U.S. Cl. ................................................................ 705/40
`
`(57)
`
`ABSTRACT
`
`According to the invention, a method for processing a
`transaction where the transaction is initiated by a payor
`online, but paid to a payee in-perSon, is disclosed. In one
`Step, payor information is accepted at a location that located
`acroSS a wide area network from the payor. Transaction
`information and payment Source information is also
`accepted at the location. The transaction information
`includes an amount and a payee identifier and the payment
`Source information includes account details associated with
`an account of the payor at a money handler. A risk related to
`a likelihood that the transaction will complete Successfully
`is evaluated. Validating that the payment Source information
`is associated with the payor is manually performed if the risk
`is excessive. The risk can generally be reduced by the
`manual validation. The money handler is billed for at least
`the amount. It is determined if the money handler settles the
`amount. Historical information on the transaction is Stored.
`
`400
`
`Refer Payor to
`Retaillocation
`
`Payor Logs into the Payment
`Enabler to Enter information
`
`412
`
`Transfer Declined
`for Online Funding
`
`Verifying Payment Source
`Information with Hadler
`
`404
`
`420
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Pass
`
`Internal Business
`
`Transaction
`Velocity Check
`
`22
`
`424
`
`428
`
`Transaction Amount Check
`& Amount Velocity Check
`Passor New Payor
`
`432
`
`Fail
`Ruestionable
`
`Evaluate Risk
`of Chargeback
`
`Fail
`
`Passbut New Payor 4.
`Authenticate Payor
`& Payment Source
`Pass
`
`Manual Walidation
`of Transaction
`
`Pass Transaction Passed to
`Handler for Funding
`
`448
`
`Complete Funding
`of Transaction
`
`Funds Available at
`Retail Location
`
`Pass
`Report Transaction & Clearing to
`Update Historical Information
`
`
`
`450
`
`APPL-1008
`APPLE INC. / Page 1 of 24
`
`

`

`Patent Application Publication Nov. 18, 2004 Sheet 1 of 11
`
`US 2004/0230527 A1
`
`100
`l
`
`160
`
`Money
`Handlers
`List
`
`140
`
`170-1
`
`Retail
`LOCations
`
`Payment
`Enabler
`
`185
`
`Failure
`Risk Scoring
`18O
`
`Authentication
`Service
`
`150
`
`20
`1
`
`130
`
`110
`
`Payin
`Interfaces
`
`Fig. 1A
`
`APPL-1008
`APPLE INC. / Page 2 of 24
`
`

`

`Patent Application Publication Nov. 18, 2004 Sheet 2 of 11
`
`US 2004/0230527 A1
`
`105
`
`160
`
`Money
`Handlers
`
`
`
`
`
`
`
`130
`
`140
`
`170-2
`
`185
`
`Payment
`Enabler
`
`Failure
`Risk Scoring
`
`Retail
`Locations
`
`
`
`120
`
`Payin
`Interfaces
`
`Fig. 1B
`
`APPL-1008
`APPLE INC. / Page 3 of 24
`
`

`

`Patent Application Publication Nov. 18, 2004 Sheet 3 of 11
`
`US 2004/0230527 A1
`
`120-1
`
`ATM
`Interface
`
`120-2
`
`Kiosk
`Interface
`
`120-3
`
`Internet
`Interface
`
`120-4
`
`Retail
`Interface
`
`120-5
`
`PhOne
`Interface
`
`160-1
`
`Retail
`Handler
`
`160-2
`
`Credit Card
`Handler
`
`160-3
`
`Debit Card
`Handler
`
`160-4
`
`Bank
`Handler
`
`17O
`
`
`
`Payment
`Enabler
`
`Fig. 2
`
`APPL-1008
`APPLE INC. / Page 4 of 24
`
`

`

`Patent Application Publication Nov. 18, 2004 Sheet 4 of 11
`
`US 2004/0230527 A1
`
`Z 19
`
`
`
`
`
`
`
`
`
`
`
`
`
`APPL-1008
`APPLE INC. / Page 5 of 24
`
`

`

`Patent Application Publication Nov. 18, 2004 Sheet 5 of 11
`
`US 2004/0230527 A1
`
`| | | | | | | | | | | | | |
`
`| | | | |
`
`| | | | | | | | | ! | | | | | | 1 | | | |
`
`
`
`
`
`
`
`
`
`
`
`
`
`APPL-1008
`APPLE INC. / Page 6 of 24
`
`

`

`Patent Application Publication Nov. 18, 2004 Sheet 6 of 11
`
`US 2004/0230527 A1
`
`400
`
`.
`
`Refer Payor tor'
`Retail LOCation
`
`Payor Logs into the Payment?"
`Enabler to Enter information
`
`2
`41
`
`420
`
`Transfer Declined Fail
`for Online Funding
`
`Verifying Payment Source
`Information With Handler
`
`Pass
`
`422
`
`Questionable
`
`Internal Business
`Rule Check
`
`PaSS
`
`424
`
`Transaction
`Velocity Check
`
`Pass
`
`428
`
`Transaction Amount Check
`& Amount Velocity Check
`or New Payor
`
`432
`Pass
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Questionable
`
`Questionable
`
`
`
`
`
`Evaluate Risk
`of Chargeback
`
`
`
`But New Payor
`Authenticate Payor
`& Payment Source
`
`Pass
`
`Manual Validation
`of Transaction
`
`Transaction Passed to
`Handler for Funding
`
`448
`
`Complete Funding
`of Transaction
`
`452
`
`Pass
`
`450
`
`Report Transaction & Clearing to
`Update Historical Information
`Fig. 4
`
`Funds Available at
`Retail LOCation
`
`APPL-1008
`APPLE INC. / Page 7 of 24
`
`

`

`Patent Application Publication Nov. 18, 2004 Sheet 7 of 11
`
`US 2004/0230527 A1
`
`500
`l,
`
`404
`
`Payor Logs into
`Payment Enabler
`
`Yes
`
`Payor Enters / Modifies Demographic,
`Payment and Transfer Information
`
`504
`
`
`
`508
`
`Check Entered
`Information for ErrorS
`
`422
`
`NO
`
`Internal Business
`Rule Check
`
`PaSS
`
`User On Internal
`Hot List?
`
`Fail
`
`516
`
`Refer Payor to
`Retail Location
`
`416
`
`412
`
`Transfer Declined
`for Online Funding
`
`(B)
`
`NO
`
`520
`
`52 4
`
`CheckUser Against
`Government Hot List
`
`Yes
`
`Investigate
`User Information
`
`
`
`False
`POSitive?
`
`
`
`
`
`
`
`Any
`Previous
`Manual
`Validation?
`
`532
`
`Set Manual
`Validation Flag
`
`(A)
`
`No
`
`
`
`540
`
`Analyze Any
`History Score
`Low or No Score
`Fig. 5A
`
`Reset Manual
`Validation Flag
`
`(A)
`
`APPL-1008
`APPLE INC. / Page 8 of 24
`
`

`

`Patent Application Publication Nov. 18, 2004 Sheet 8 of 11
`
`US 2004/0230527 A1
`
`424
`
`(A)
`
`544
`
`Transaction
`Volume Check
`
`Fail
`
`Aggregate
`Amount Check
`
`548
`
`Pass
`
`
`
`552
`
`Reset Manual
`Validation Flag
`
`Return at
`Next Step
`v
`
`Transaction
`Threshold Check
`
`Pass
`
`Any Response
`Code
`
`
`
`Existing User
`Yes and
`
`No and MV Flag Reset
`
`Score Risk
`of Chargeback
`
`556
`No and
`MV Flag Set
`
`560
`
`n
`
`564
`
`Pass and Set MV Flag
`
`If Set, Do Not
`Manually Validate
`
`Not Set
`
`
`
`Manually Verify
`Transaction
`
`
`
`440
`
`Transaction Passed to
`Handler for Funding
`
`448
`
`
`
`Complete Funding
`of Transaction
`
`452
`
`Pass
`
`450
`
`Funds Available at
`Retail LOCation
`
`Report Transaction & Clearing to
`Update Historical Information
`Fig. 5B
`
`APPL-1008
`APPLE INC. / Page 9 of 24
`
`

`

`Patent Application Publication Nov. 18, 2004 Sheet 9 of 11
`
`US 2004/0230527 A1
`
`600
`
`Payor Enters / Modifies Demographic,
`Payment and Transfer Information
`
`604
`
`re
`Internal Business Rule
`& Velocity Checks
`Pass
`608
`
`Verifying Payment
`Source & Hot Lists
`
`504
`
`404
`Payor Logs into
`Payment Enabler
`
`416
`Refer Payor to
`Retail Location
`
`412
`
`Transfer Declined
`for Online Funding
`
`Determine History
`Score & Code(s)
`High Score &
`No Bad Codes
`
`616
`
`Low Score or
`Bad Codes
`
`Transaction Passed to
`Handler for Authorization
`
`528
`
`
`
`
`
`
`
`Previous
`Manual
`Validation?
`
`620
`Report Transaction & Failure to
`Update Historical Information
`
`Yes|(Set BHV Flag)
`
`No.(Clear BHV Flag)
`
`
`
`Fig. 6A
`
`APPL-1008
`APPLE INC. / Page 10 of 24
`
`

`

`Patent Application Publication Nov. 18, 2004 Sheet 10 of 11
`
`US 2004/0230527 A1
`
`650
`
`548
`
`Mid-Range YN Amount Check
`
`LOW
`
`424
`
`LeSS Than
`Threshold
`
`Transaction
`Volume Check
`
`Greater Than
`Threshold
`
`
`
`(C) KME SE
`
`
`
`No (High Range
`
`654
`
`
`
`
`
`Bypass
`Validation
`Flag Set?
`
`
`
`
`
`658
`
`Yes
`
`
`
`
`
`
`
`Favorable History
`On Other Services?
`
`444
`
`Manually Verify
`Transaction
`
`
`
`448
`Complete Funding
`of Transaction
`PaSS
`
`450
`
`(D)
`
`Report Transaction & Clearing to
`Update Historical Information
`
`452
`
`Funds Available at
`Retail LOCation
`
`Fig. 6B
`
`APPL-1008
`APPLE INC. / Page 11 of 24
`
`

`

`Patent Application Publication Nov. 18, 2004 Sheet 11 of 11
`
`US 2004/0230527 A1
`
`Payor Enters / Modifies Demographic,
`Payment and Transfer information
`
`
`
`504
`
`404
`Payor Logs into
`Payment Enabler
`
`Internal Business Rule
`& Velocity Checks
`PaSS
`608
`
`700
`
`Verifying Payment al
`Source & Hot Lists
`
`Refer Payor to
`Retail Location
`
`412
`
`Transfer Declined
`for Online Funding
`
`
`
`Determine History
`Score & Code(s)
`Low Score or
`Bad Codes
`
`528
`
`
`
`
`
`
`
`Previous
`Manual
`Validation?
`
`
`
`620
`Report Transaction & Failure to
`Update Historical Information
`
`High Score &
`No Bad Codes
`
`616
`
`
`
`Transaction Passed to
`Handler for Authorization
`
`448
`Complete Funding
`of Transaction
`
`Pass
`
`450
`
`Report Transaction & Clearing to
`Update Historical Information
`
`704
`
`Funds Available at Retail LOCation or
`Automatically Transferred to Payee
`
`Fig. 7
`
`APPL-1008
`APPLE INC. / Page 12 of 24
`
`

`

`US 2004/0230527 A1
`
`Nov. 18, 2004
`
`AUTHENTICATION FOR ONLINE MONEY
`TRANSFERS
`0001. This application claims the benefit of and is a
`non-provisional of U.S. Application Ser. No. 60/466,871
`filed on Apr. 29, 2003, which is incorporated by reference in
`its entirety.
`
`BACKGROUND OF THE INVENTION
`0002 This invention relates in general to online money
`transferS and, more specifically, to payment authentication
`for online money transferS.
`0003. An ever-increasing amount of commerce is being
`done online. Unique ways to Send money are being devised
`to ease the flow of money for online transactions. Inherent
`to online transactions, the parties never meet in perSon Such
`that the parties enjoy a certain amount of anonymity. Crimi
`nals find comfort in this anonymity which is reflected in the
`fraud Statistics for online transactions.
`0004) To capitalize upon online commerce, while reduc
`ing the fraud risk, new methods of payment authentication
`have been devised. There are address verification services
`that check the address provided against the billing address
`with the credit card company. Modern credit cards have a
`CVV2 code imprinted on the back or front of the credit card
`that is not part of the credit card number. Authenticating that
`the buyer has the proper CCV2 code tends to show the buyer
`physically has the card. Similarly, Some authenticate the
`customer Service number on the credit card.
`0005 Some credit cards have an embedded semiconduc
`tor chip that can have various features to reduce the risk of
`fraud. These new cards are called Smart cards. A card reader
`is necessary at the Internet terminal the purchaser is using to
`take advantage of the Smart card feature. In certain coun
`tries, the adoption of Smart cards is at insignificant levels.
`0006. One type of online transaction subject to the above
`fraud concerns is the Sending of money using online pay
`ment to fund the transfer. For example, there are Services
`offered by Western Union.com TM that allow using a credit/
`debit card to make money available for pickup at a retail
`Western UnionTM location. As the money can be paid out
`almost immediately, authentication of the Sender and their
`card is important to reduce the risk of fraud. Once the money
`is picked-up, the true owner of the card may dispute the
`charge leaving little chance of recovery.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`0007. The present invention is described in conjunction
`with the appended figures:
`0008 FIG. 1A is a block diagram of an embodiment of
`a money transfer System;
`0009 FIG. 1B is a block diagram of another embodiment
`of a money transfer System;
`0.010
`FIG. 2 is a block diagram of an embodiment of
`portions of the money transfer System;
`0.011
`FIG. 3A is a block diagram of an embodiment of
`a payment enabler;
`0012 FIG. 3B is a block diagram of another embodiment
`of a payment enabler;
`
`0013 FIG. 4 is a flow diagram of an embodiment of a
`process for performing a money transfer;
`0014 FIGS. 5A and 5B are block diagrams of another
`embodiment of a process for performing a money transfer;
`0.015 FIGS. 6A and 6B are block diagrams of yet
`another embodiment of a proceSS for performing a money
`transfer, and
`0016 FIG. 7 is a block diagram of still another embodi
`ment of a process for performing a money transfer.
`0017. In the appended figures, similar components and/or
`features may have the same reference label. Further, various
`components of the Same type may be distinguished by
`following the reference label by a dash and a second label
`that distinguishes among the Similar components. If only the
`first reference label is used in the Specification, the descrip
`tion is applicable to any one of the Similar components
`having the same first reference label irrespective of the
`Second reference label.
`
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENT
`0018. The ensuing description provides preferred exem
`plary embodiment(s) only, and is not intended to limit the
`Scope, applicability or configuration of the invention.
`Rather, the ensuing description of the preferred exemplary
`embodiment(s) will provide those skilled in the art with an
`enabling description for implementing a preferred exem
`plary embodiment of the invention. It being understood that
`various changes may be made in the function and arrange
`ment of elements without departing from the Spirit and Scope
`of the invention as Set forth in the appended claims.
`0019. In one embodiment, the present invention provides
`a method for processing a transaction where the transaction
`is initiated by a payor online, but paid to a payee in-perSon.
`In one Step, payor information is accepted at a location that
`is located acroSS a wide area network from the payor.
`Transaction information and payment Source information is
`also accepted at the location. The transaction information
`includes an amount and a payee identifier and the payment
`Source information includes account details associated with
`an account of the payor at a money handler. A risk related to
`a likelihood that the transaction will complete Successfully
`is evaluated. The transaction information is checked against
`a usage limit. Validating that the payment Source informa
`tion is associated with the payor is manually performed if the
`risk is excessive. The risk can be reduced by the manual
`validation. The money handler is billed for at least the
`amount. It is determined if the money handler settles the
`amount. Historical information on the transaction is Stored.
`0020. In another embodiment, the present invention pro
`vides a method for processing a transaction where the
`transaction is initiated remotely, but paid to a payee in
`perSon. In one Step payor information is accepted at a
`location that is located acroSS a wide area network from the
`payor. Transaction information and payment Source infor
`mation is also accepted at the location. The transaction
`information includes an amount and a payee identifier and
`the payment Source information includes account details
`asSociated with an account of the payor at a money handler.
`At least Some of the payment Source information is verified.
`A risk related to a likelihood that the transaction will
`
`APPL-1008
`APPLE INC. / Page 13 of 24
`
`

`

`US 2004/0230527 A1
`
`Nov. 18, 2004
`
`complete Successfully is evaluated. A human manually vali
`dates that the payment Source information is associated with
`the payor if the risk is excessive. The money handler is billed
`for at least the amount.
`0021. In yet another embodiment, a method for process
`ing a transaction that transferS money or its equivalents from
`a payor to a payee is disclosed. In various Steps, payor
`information, transaction information and payment Source
`information is accepted from a payor who is located acroSS
`a wide area network. The transaction information includes
`an amount and a payee identifier. The payment Source
`information includes account details associated with an
`account of the payor at a money handler. At least Some of the
`payment Source information is verified. A risk related to a
`likelihood that the transaction will complete Successfully is
`evaluated. The transaction information is checked against a
`usage limit. It is manually validated that the payment Source
`information is associated with the payor if the risk is
`excessive or the usage limit is violated. The money handler
`is billed for at least the amount.
`0022 Referring first to FIG. 1A, a block diagram of an
`embodiment of a money transfer system 100 is shown. In
`this embodiment, the payor 110 can Send money to a payee
`130 that is available for pick-up at any of a number of retail
`locations 140. Depending on authorization, the money is
`available in a few minutes with automated authorization or
`a few hours with manual authorization. In this way, the
`payor 110 can make money available to the payee 130 in
`10-15 minutes despite any large geographical Separation
`between the payor 10 and payee 130. Included in the money
`transfer system 100 are payin interface(s) 120, a wide area
`network (WAN) 150, a payment enabler 170, a failure risk
`scoring service (FRSS) 185, an authentication service 180,
`money handler(s) 160, and one or more retail location(s)
`140.
`0023 The payor 110 uses one of the payin interfaces 120
`to interact with the payment enabler 170 over a WAN 150.
`The WAN 150 could be a private network or a public
`network, Such as the Internet. In Some embodiments, a
`circuit Switched network could be used instead of a packet
`Switched network for the WAN 150. In various embodi
`ments, the payin interface 120 could be a web browser,
`custom application Software, a phone interface, a retail
`interface, a kiosk interface, or an automated teller machine
`(ATM) interface as is further explained in relation to FIG.
`2 below.
`0024. The payment enabler 170 manages operation of the
`money transfer system 100. Using the payment enabler 170,
`the payor 110 enters payor information, transaction infor
`mation and payment Source information to Set up a transfer
`to the payee 130. If the payor 10 has an existing account with
`the payment enabler 170, some previously entered informa
`tion can be reused for Subsequent transactions. The trans
`action information includes an amount of the transfer and an
`identifier for the payee 130. The payee identifier can be any
`group of characters that identifies the payee, Such as a name,
`an e-mail address, a test phrase, an account number, and an
`identification number. The payment Source information pro
`vides information for receiving money from an associated
`money handler 160 and can include an account number and
`a bank routing number for a bank handler 160; an account
`holder name, a card issuer phone number, an account billing
`
`address, and/or a CVV2 code for a credit/debit card handler
`160; or retail store identification information for a retail
`handler 160. Information to identify the payor 110 is
`included in the payor information, Such as a user ID, a
`password, a driver's license number, a payor's name, an
`address, a Social Security number or portion thereof, a
`maiden name, a mothers maiden name, an age, a date of
`birth, and/or other personal information.
`0025 To reduce the risk that a transaction will be suc
`cessfully performed and that the payment transfer will Settle,
`the FRSS 185 and the authentication Service 180 are used.
`The FRSS 185 Scores the risk the transaction will result in
`a charge/debit card chargeback or a bounced electronic
`check. Some or all of the payor information, transaction
`information and payment Source information is passed to the
`FRSS 185, which produces a numerical score. Additionally,
`an IP address used by the payor 110 is passed to the FRSS
`185 such that an approximate physical location of the
`payor's payin interface 120 can be determined and com
`pared against the payor information. The FRSS 185 uses
`regression analysis against historical information on other
`transactions and/or information gathered outside the money
`transfer system 100 to produce the numerical score. The
`payment enabler processes the Score to decide if the trans
`action should progreSS further, fail or be verified manually
`by a human operator. After each transaction or in a periodic
`batch, information on transactions is passed to the FRSS 185
`to update the historical information. Included in the histori
`cal information is a failure risk Score, an authentication
`Score, a Settlement result, the payor information, the trans
`action information, and the Source information. The histori
`cal information could also include reason codes from the
`Scoring processes to explain reasons for the Scores. This
`embodiment uses a CCScanTM product available from
`Shared GlobalTM for the failure risk scoring service 185. In
`this embodiment, updating of the historical information
`allows the failure risk Scoring to adaptively Score risk. In
`Table I below, possible reason codes or response codes for
`one embodiment are shown.
`
`TABLE I
`
`Reason
`Code Code Description
`O1
`Important Application Data Missing
`O2
`Deceased Social Security Number (SSN)
`O3
`SSN Issued Prior to Date of Birth
`O4
`Possible Stolen Identity Fraud
`05
`Possible Move-In Fraud
`O6
`Invalid or Unissued SSN
`O7
`Potentially Disconnected Telephone Number
`O8
`Invalid Telephone Number
`O9
`Telephone Number is Pager
`1O
`Telephone Number is Assigned to Mobile Service
`11
`Invalid Address
`12
`Zip Code Assigned to Post Office Box Only
`13
`Address has Suspect Apartment Unit Designation
`14
`Higher Risk Commercial or Institutional Address
`15
`Higher Risk Commercial or Institutional Telephone Number
`16
`Telephone Number Zip Code Mismatch
`17
`Full Name and Address Matches on High Risk DM File
`18
`Significant Address Matches on High Risk DM File
`19
`Unable to Verify Applicant Name, Address,
`SSN and Telephone Number
`Unable to Verify Applicant Name, Address and
`Telephone Number
`Unable to Verify Applicant Name and Telephone Number
`
`2O
`
`21
`
`APPL-1008
`APPLE INC. / Page 14 of 24
`
`

`

`US 2004/0230527 A1
`
`Nov. 18, 2004
`
`TABLE I-continued
`
`Reason
`Code Code Description
`22
`Unable to Verify Applicant Name and Address
`23
`Unable to Verify Applicant Name and SSN
`24
`Unable to Verify Applicant Address and SSN
`25
`Unable to Verify Applicant Address
`26
`Unable to Verify Applicant SSN
`27
`Unable to Verify Applicant Telephone Number
`28
`Unable to Verify Applicant Date of Birth
`29
`Potential Data Miskey - SSN
`3O
`Potential Data Miskey - Address
`31
`Potential Data Miskey - Telephone Number
`32
`Match to Office of Foreign Assets Control (OFAC)
`34
`Incomplete Verification
`
`0026. The authentication service 180 is used to score a
`risk that the payment Source information is not associated
`with the payor 110 by authenticating the payment Source and
`payor 110. Fraud often occurs where a payor imperSonates
`another after Stealing payment information. The authentica
`tion service 180 scores this risk using various databases to
`check the payor information and the Source information. In
`one embodiment, a First Data Solutions TM product called
`Fast InformerTM or Fraud IDTM is used. Other embodiments
`could use Instant ID Plus TM from Risk Wise TM, Clear Com
`merce TM, and/or Retail DecisionsTM products. A risk score is
`produced by the authentication service 180, which is ana
`lyzed by the payment enabler 170 to determine if the
`transaction should be approved, denied or manually verified.
`0027. In this embodiment, the authentication service 180
`detects fraud based on confirming the identity of the payor
`110 and validating the payor information, transaction infor
`mation and payment Source information against databases.
`This technique addresses at least the following types of
`fraud: Stolen payment Source information, Stolen identities,
`move-in fraud, and created identity fraud. Payor information
`is validated by checking that the phone numbers and
`addresses are valid. Also, the payor information, Such as the
`name, address, phone number, Social Security number, driv
`erS license number, and date of birth, can be checked for
`consistency against consumer reporting agencies and public
`record databases. Some embodiments may only collect and
`check a portion of the Social Security number. The payor
`information is checked against high-risk databases, Such as
`phone numbers recently disconnected, consumers that have
`recently moved from the payor's State, consumerS reported
`as deceased, consumerS filing bankruptcy, high-risk
`addresses (e.g., hotels, campgrounds, correctional facilities,
`etc.), Social Security number of a deceased consumer, and
`Social Security numbers issued prior to the date of birth.
`Transaction information and payment Source information is
`Scrutinized by checking for first time users of the payment
`Source or the Velocity of recent activity with the payment
`Source originating with the money transfer System 100 and
`elsewhere.
`0028 Money handlers 160 serve as the source for money
`into the transfer system 100. The payor 110 has an existing
`relationship with the money handler 160 that allows paying
`for things. Examples of money handlers 160 include retail
`location handlers, credit/debit card handlers, and bank han
`dlers. Payment Source information provided by the payor
`
`110 allows interfacing with the handlers 160 to payin money
`from an account of the payor 110.
`0029. In this embodiment, payment is made to the payee
`130 at a retail location. Examples of retail locations include
`Western UnionTM locations, check cashing store fronts,
`payday loan Stores, currency exchanges, bill payment Stores,
`banks, etc. These retail locations 140 are arranged in an
`affiliate network Such that the payor may specify any loca
`tion 140 for making the money available. In some embodi
`ments, the payee 130 does not have a specified retail location
`140, but can receive the money at any retail location 140.
`The retail location 140 verifies the payee is properly asso
`ciated with the identifier specified by the payor 110. In some
`cases, this may involve asking for a test phrase or password
`from the payee or checking identification in the conventional
`manner. Some embodiments may use biometric information
`to further verify the identity of the payee 130.
`0030. With reference to FIG. 1B, a block diagram of
`another embodiment of a money transfer system 105 is
`shown. This embodiment includes a FRSS 185, but not a
`separate authentication service 180. Authentication of the
`user in this embodiment is performed by evaluating the risk
`of chargeback.
`0031. In this embodiment, there are generally three tests
`performed by the FRSS 185. The first test relates to iden
`tification of the location of the payor. Location information
`may be gathered differently for the different payin interfaces
`120, more specifically, the phone interface 120-5 gathers
`caller ID information; the retail, kiosk and ATM interfaces
`120-4, 120-2, 120-1 provide their known location; and the
`Internet interface 120-3 can gather IP addresses and clock
`Settings for the terminal the payor 110 is using. By knowing
`the IP address and clock Settings for the payor's computer,
`the approximate location and time Zone can be presumed.
`Where the current location of the payor discerned through
`this proceSS does not match the billing location associated
`with the handler 160 within some margin of error, a
`“Exceeds Card Profile” response code is generated.
`0032. A second test can result in generation of other
`response codes. This Second test compares information
`provided by the payor 110 against historical information
`from previous transactions. Multiple criteria are used to
`analyze the provided information. Additional response codes
`are possible from this analysis. Table II lists the six possible
`response codes for this embodiment.
`
`Response
`Code
`
`210
`215
`22O
`225
`230
`250
`
`TABLE II
`
`Code Description
`
`Negative Account Record
`Negative Location History
`Account With Chargeback History
`Location With Chargeback History
`Exceeds Card Profile
`Transaction Exceeds Location Profile
`
`0033. The third test performed by the FRSS 185 involves
`Scoring the information provided by the payor 110 against
`historical norms. Every new transaction is entered into the
`FRSS 185 to update the historical database. As chargebacks,
`non-Sufficient funds notices, or other unfavorable Settle
`
`APPL-1008
`APPLE INC. / Page 15 of 24
`
`

`

`US 2004/0230527 A1
`
`Nov. 18, 2004
`
`ments are determined that information is used to update the
`prior recorded transaction information. A numerical Score
`between 0-999 is produced for each presented transaction.
`One or more Score thresholds could be used to trigger Such
`things as declining to fund the transaction online or requir
`ing manual human validation of the transaction. In one
`embodiment, a Score below 336 requires manual validation
`before the transaction is funded. Although this embodiment
`has the FRSS 185 performing a different process for assess
`ing the risk of chargeback than that of FIG. 1A, various
`embodiments could mix and match test elements from the
`above embodiments.
`0034). With reference to FIG. 2, a block diagram of an
`embodiment of portions of the money transfer system 100 is
`shown. This embodiment includes five different payin inter
`faces 120 and four different money handlers 160 that are
`connected to the payin enabler 170. Other embodiments
`could include a subset of the payin interfaces 120 and money
`handlers 160 or could include others not shown in this
`embodiment. This figure shows the payin interfaces 120
`directly connected to the payment enabler 170, but this
`connection could be a virtual connection through the WAN
`or Internet 150.
`0035. The payor 110 is given a variety of ways to interact
`with the payment enabler to configure a transaction. Addi
`tionally, the payee 130 could interact with the payin inter
`faces to facilitate payout in Some embodiments. The five
`types of payin interfaces 120 shown include an ATM inter
`face 120-1, a kiosk interface 120-2, an Internet interface
`120-3, a retail interface 120-4, and a phone interface 120-5.
`Information Such as the payor information, transaction infor
`mation and payment Source information is entered using the
`payin interface 120 to configure a transfer. Typically, the
`payin interface 120 is remote to the payment enabler 170,
`but is available to the payor 110. The payor 110 can
`interchangeably choose any payin interface 120 that is
`convenient to configure a transfer.
`0.036 When the payor 110 configures the first transaction,
`the entered information can be retained and associated with
`an account for the payor 110. For Subsequent transactions,
`only a user name, password, and transaction information
`need be entered if the previously entered information is still
`applicable for the current transaction. The payor 110 is given
`opportunity to change the payor information and payment
`Source information that may have changed since the last
`transaction or may otherwise warrant changes.
`0037. The ATM interface 120-1 may be an application
`that runs on various ATMs located around the world. ATM
`cards and credit/debit cards could be machine read by the
`ATM to configure the interface to the associated money
`handler. Other information could be entered with a keypad.
`In some embodiments, the ATM may have a web browser
`interface application that connects to the payment enabler
`170 to configure a transaction. Similar to an ATM with a
`browser interface, a kiosk interface 120-2 could be used to
`enter information into the payment enabler 170 in a similar
`C.
`0038. The Internet interface 120-3 is a web browser
`interface that reads pages from the payment enabler 170.
`This interface 120-3 is accessible by the payor 110 from any
`personal computer that has a web browser connected to the
`WAN or Internet 150. In some cases, customized application
`
`Software could be loaded onto a computer accessible to the
`payor 110 to allow interface with the payment enabler 170.
`0039. One option the payor 110 has is to visit a retail
`location to payin the funds for a transaction. The retail
`location could have a kiosk 120-2 available for entering the
`information or a clerk could Solicit the necessary informa
`tion for entry into the retail interface 120-4. There is also the
`option wher