Exploring the Indian Tribal Organizations (ITO) Model Further

The Indian Tribal Organizations (ITO) model allows me to use the concepts I talked about in earlier blogs (see for example the Basic Concept articles) and some of the structures discussed (see for example the Insurance for Electronic Transactions or Turnstiles). Now we can put the elements together fully and build an interchangeable small value gross real time payment system (SVGRTP) and its accompanying monitor and put it in a kit. Diagram 19 shows an expanded diagram of the ITO SVGRTP.

Diagram 19 More Details for an ITO SVGRTP

Diagram 19 shows several structures that require explanation and definition.

Taxes

Taxes used in this design are an account(s) receiving funds from traffic flow at a configurable percentage for a discreet time period. The monitor design allows configuration of the tax switch. For example, I will create two tax accounts for the ITO SVGRTB. One I will name the old chief’s benevolent fund, and the other I will name the ITO SVGRTB capital improvement fund. I set the goal of the benevolent fund at a 1000 dogmas from the planet Criterion in the region of Plato. I set the rate at .035% and throw the automatic cutoff switch. I have no goal for the improvement fund and set the rate .0122% and the currency type. I can configure the monitor to show actual and projected acceleration and velocity of funds traffic to tax pools.  I chose to place the tax siphon where it is quite arbitrarily; The ITO can place it anywhere multiple times; its position and multiple instantiations has quite a few consequences.

Outside Access

All outside traffic arrives at the ITO SVGRTP in a standard data protocol, preferably an ISO standard. At some point I will publish a HTML tagged standard (using ISO 20022 as a guideline) that will encapsulate all traffic possible in and out of the ITO SVGRTP. I hope also to set up a project where I can gather the funds and the technical talent for an ISO technical committee to hammer out the details of an international specification. However all that is later, Diagram 19 does not show possible extensions between the access point and the SVGRTP. For example the ITO may decide that they do not want to issue virtual currency to the public, so they sell the production to a certificate authority (CA) and the CA in turn allows consumers to insure the currency purchased before issuance from an independent insurance marketplace. Many such configurations are possible; however each configuration need an evaluation for risks and vulnerabilities.

Access to Other SVGRTP

The access to other SVGRTP in some respects is the common light bulb threading that allows any organization to connect with any other and perhaps swap retailer databases depending on how close a relationship they want to form. As shown the ITO can create any administrative and auditing controls they see fit. The data protocol for the flow should use the same ISO 20022 type standard discussed earlier.

Next Blog: Connecting the ITO SVGRTP to Other Organizations

Indian Tribal Organizations as a Model for a Modern Payment System

I chose generic Indian Tribal Organizations as a model small value gross real time payment system (SGRTP) for several reasons namely:

• Relatively Small payment hubs interspersed with large Cash Pools
• Sufficient trust likely among disparate organizations (might just be my imagination)
• I do not know how they actually work or their actual connectivity and have never advised them professionally
• Presumed Access to sufficient technology to make it work
• Currently providing access to goods and services using card clearing and deferred net settling (presumed on my part but I have used a card on a reservation)
•  Sufficient ubiquity for the purposes of the design

Diagram 18 shows the concept.

Diagram 18 Concept for an ITO SVGRTP

Diagram 18 depicts two Indian Casino Payment hubs linked by a novus vovus (on-us, on-you) payment account. The accounts are database structures and updated in real time (show the exact position of the funds from the separate casinos). The retailer database contains numbers that represents a retailer account for any or all members of the tribal organization that want a number. The number is associated with an account housed in the casinos with the novus vovus structure. On a daily basis the following events occur within the SVGRTP system:

• Worldwide issuance of virtual currency by consumer purchase
• Worldwide redemption of virtual currency by personal electronic device or retail operations
• Worldwide validation or cancelation of virtual currency in circulation

Retailers offer goods and services from the internet or from brick and mortar institutions. Retailer will promote use of virtual currency because Regulation E would not govern the funds and there are no charge backs, payment system fees, or surcharges.  Purchases appear as credits in the casino account structure. Retailers use their accounts to push funds to other entities as they see fit and as demand increases for retailer numbers outside of tribal organizations.  The computer structure exists in each casino; payments update accounts in real time; proper redundancy for connecting networks and account hardware minimizes operational risks. Consumers store coins securely on any personal electronic device and can revoke them if stolen or accidentally destroyed.

The resulting increasing concentration of funds will allow the growth of retail payment services and profits can come from conventional retail banking operations (making loans and accepting deposits) and not from the fees of their retailers. The growth of retail operations increases funds for other financial operations while charging fees restricts the growth. 

Next Blog: Do Payment hubs require financial institutions to function?

Insurance for Electronic Transactions

The Federal Reserve created Regulation E (Reg. E) to enforce the Electronic Funds Transfer Act. Card issuers assumed liability for failed or disputed transactions and pulling money from consumer accounts became the norm. I discussed small value gross real time payment systems (SVGRTP) (Ad nauseam perhaps patient reader(s)) and why a push from consumer accounts lowers risk. However with any payment system, and particularly retail payment systems, disputes, theft, and failed transactions create the potential for unreimbursed liability.

I believe there is a relationship between transaction value; distance between payer and payee; and time to strongly authenticate a payer, and that we can quantify that relationship with a scalar value. Further we can use the resultant scalar value to quantify relative risk of any particular electronic payment.  We can count on people getting together to bet on the outcome of human endeavor regardless of its speed or periodicity.

Is there a market for funds transfer liability? Are we on the verge of seeing traders see a blinking light setting a price for a 100,000 PIN transactions under $100 from store x, or consumers purchasing goods and services in region Y, or passengers paying for a flight? Will insurers sell policy covering payment system losses to individual consumers? Will my signed purchase of a liter of soda from a regional chain within 1 mile of my home address promote multiple zero sum bets?

Will retailers buy or sell these policies because it costs less than paying payment system networks exorbitant prices for artificially created risk?  

Perhaps dear reader(s), perhaps

Next Blog: Knitting concepts together, or, response to comments, or do you want to get geeky with me?

Real Price of Risk and Who Covers the Bet

Retailers pay for an authorization code and yet might not receive payment. Effectively, retailers pay for the cost of risk likely chosen by the customer. That does not seem a good way to price risk, which is the critical component of price in electronic funds transfer.  It’s akin to a landlord determining the risk of fire damage for a rental unit without a fire extinguisher and then demanding a price for the risk with no competing bids allowed and only allowing purchase of authorized fire extinguishers from the landlord. 

In a mythical world where my proposed small value gross real time payment system (SVGRTP) reigns as the leading backbone of international retail payments, insurers of transactions will add a surcharge payable by the party increasing the risk of non-payment. For example the initiation of payment may follow the decision logic shown in diagram 17 

Diagram 17 Decision Tree for Initiation of Payment in a SVGRTP

Each of the processes may have a number of known steps and each step has a cost if not completed. For example the Device validates the device process may contain 3 steps, namely:

1. User validation application address is in the correct interrupt vector.
2. Check sum of user validation application computes correctly
3. User validation application validates cryptogram generated from secure area on device

The entity that provided the software for the device to the user may skip a few of the steps or the user may opt not to run the validation phase at all. The insurer of the transaction prices the risk surcharge accordingly and the consumer pays for the risk created by choice. Similarly the retailer may not wish to have the POP authorize the device, and pays a surcharge to the insurer for that choice. The transaction completes, the insurer receives the surcharges immediately, and the insurer pays unsatisfied parties and tries to recoup the cost from the party benefitting materially from a failed transaction.

There are lots of technical details I did not cover here such as does each transaction have two insurers, one for the consumer and one for the retailer, and what if a party to a  transaction claims to compete a validation and does not. I am not going to worry my pretty head about details, because that is not the point of this discussion. The point is that increase in quantifiable risk results from choice and each party to a transaction needs to pay for the choices they make affecting risk.

Next Blog: Does an independent insurer make sense for the retail payment industry?

Card Not Present Fraud

Card Not Present Fraud (CNP) as a term is a misnomer. It implies a card is a requirement for payment when it is not. Customer Not Present does not work as a proper definition because a customer can be present but usual or standard authentication procedures are not available at the point of sale. I am willing to step out on a limb and define a new term “Remote Vulnerability” (RV). Further I choose to consider RV is a cardinal value on a calibrated scale based on price because it is my blog and my term, dear reader(s).

For the sake of brevity I will use symbols to describe the concept. Let P be a unit of value and R be a distance. Define RV as PRⁿ/P, where n is the time to authenticate the payment system user.

New definition carefully in hand can we price a service. I will go out on a limb again and say yes.

Next Blog: Lemmings

The False Positive False Negative Dialectic

Unlike neural networks, payment system filters do not look at specific actions of consumers and then make decisions based on individual historic patterns. Payment system filters examine the minutiae of specific payment hubs and detect behavior unlikely (the more unlikely the better) to occur in that exact circumstance. Earlier blogs showed focusing on payer location can show impossibility in one case, and an attempt to deceive in another case. Detection of facts like these form the foundation of low false positive results, which I believe, should be the basis for flagging transactions as fraudulent.

There is room for disagreement with regards to low false positives. Some reason that it is better to have more false positive than false negatives since the latter create the greatest protection against financial loss regardless of inconvenience to payment system users. I think fraud detection implementers should have lots of tools in their belt and just like choosing between power and economy settings in some modern cars, detection implementers should be able to set the percentages based on perceived threats, customer requirements, and real cost.

Consider insurance companies making payments after a storm. Concern for fraudulent claims versus concern for rapid payment is different than it is for a claim made with few others in like circumstances. Events like the World Cup now transpiring in Brazil force a surge of value throughout the entire payment system increasing backpressure and the request for speedier authorizations and the subsequent increase to vulnerability to fraud.  Increasing throughput for short periods makes little economic sense yet there it is, increase vulnerability, or increase throughput. Without adding hardware, the only choice the local industry can do to increase throughput is loosen fraud detection parameters. The phenomena works with any surge of human activity, be it security personnel on duty during rush hour at the airport, or firemen on duty during the Fourth of July (US Independence Day celebrated with Fireworks). The choices are few: spend more money, increase the risk, or increase the efficiency of response methods.

Constructing filters for payment systems require domain experts on specific incarnations of payment hubs. For example, a government payment hub payee will have finite ways for disguising false claims. The difference in data between a false claim and a legitimate one may not be discernible at all; however, only people intimately familiar with the complete data set for the entire transaction can create filters to separate the two.   Once in place filters can work in conjunction with other detection methods creating more false positives and less false negatives. Operators of payment systems can then throttle throughput based on management requirements of user convenience and vulnerability. Initially the requirements for a domain expert increase the cost of the entire system and  justifiable only by cost saving from reduction in false payouts.

Next Blog: What makes international Retail Payments so risky and expensive?

Why Focusing on Consumer Behavior Alone Leaves Fraud Detection Vacuums

Fraud detection systems ignore a major signal of attacking behavior because they waste precious cycles on processing consumer activity. I discussed that a bit in Fraud Detection Methods Create too many False Positives, and now want to look at the data resulting from behavior detection filters. I named the processing of data resulting from behavior detection as “Evasion Detection Filters”.  It is possible to examine the results from evasion detection filters, leisurely with batch processes.

The two processes, behavior detection and evasion detection filters are closely related and influence each other as illustrated in Diagram 16.

Diagram 16 Behavior Detection Evasion Detection Filter Interaction

The concept is quite simple. Attackers hide their methodology as best as they can until caught, and then they quickly abandon the newly discovered attack and seek another method. This abandonment leaves traces and if handled properly can set up natural defenses before a new type of attack begins. As the diagram suggests the results of evasion detection filters allow the creation of new behavior detection filters.

As an example of a BD/ED pair (behavior detection/evasion detection) is the old split purchase. A split purchase behavior suggests the payer and the payee collude to lower a price sent to an authorizer for approval because the behavior prevents examination of the true price of the purchase. Fraud detectors augmented the original behavior (high price purchase) with detection of the evasion i.e. the split purchase.  Once a payee realizes that split purchases receive processing scrutiny, and not wishing to stop the activity, payees may well try another stratagem such as delaying the time of initiation of the second purchase. The ED filter picks up the stratagem because analysts determined it a reasonable stratagem for the seller to pursue. Now however, a behavior detection filter detects the behavior in real time.

Another good function of the ED filter is its ability to show when a BD has ceased to function effectively because of successful evasions to it. Once stale, fraud detectors need to remove BDs because they waste cycles without meaningful returns.  

Next Blog: Unusual Properties of Accelerating Payment Flow