The 3 Pipe Problem

I face a conundrum. The simple problems I have addressed so far in this blog are nothing more than diversionary explorations.  Payment system architecture fascinates me because humans deploy payment architecture without too much thought, like deploying an ironing board and a badly wrinkled shirt. The shirt winds up without too many wrinkles but the electric bill, storage of the board and the iron plus payment for the storage space are not worth looking a bit less wrinkled, The pig looks better with lipstick goes only so far.

Enough philosophy, you dear reader(s) did not pay good money to read about laundry problems. Sloppy payment system architecture causes increased costs for everyone that uses it. Some of those costs can knock out small companies, or cripple a nation’s economy, or cause wars.

If we look at the horrible conflicts causing untold misery and ask why people fight for a scrap of sand, a single answer presents itself, because they have nothing else to do. Why is there no money to employ people willing to work?  Do these wars exist because the payment services industry charges too much and gives too little? Maybe. One thing is certain, the payment systems in the current war zones are not functional.

I am only posting these blogs on my "followers" section in  Linkedin. I am wrestling with a 3 pipe problem; is it possible to construct a payment system that serves everyone equally well. I will continue to write on the topic, but with less broadcasting.  

Next Blog: Moriarty

Apathy

If you read about attacks that occurred last December on retailer point of sale equipment one point becomes quite clear, the attacks are not against the retailer, the attacks are against their customers. More precisely the attacks are against the customer’s financial institutions because they are liable for the losses. If I write a check (which I haven’t done for many years) I give the payee more than access to my demand deposit account; I give the payee critical data that they can use to rob me. If I write a check to a retailer and they put it in a drawer, and someone comes and copies it and every other check in the same drawer, then puts them back in the drawer, the retailer would never notice. When those data form the basis for a series of attacks against the retailer customers, no one may realize the point of origin of the attack, and if the origin is determined, the retailer still is not liable since they put the data in a locked drawer and otherwise handled them according to best business practices. Unless the attacks become widespread, the retailers will not worry about a future attack, nor change their practices of handling checks, and generally not concern themselves with the handling of vulnerable financial data. This apathetic response is alive and well and resident in big box retailers near you.

A point of sale (POS) device connects to an electronic cash register (ECR) through a physical port. Internally that ECR port has a buffer where the POS data goes and an interrupt vector with the address of the application that will pick up the data and process it. This buffer is a RAM address. An attacking program then needs to use either the address of the buffer, the address of the application handling the buffer, or the address of the port where the application processing the data places the processed data. The three addresses coupled with assembler instructions to move the data should only occur within the appropriate drivers (terminate and stay resident applications) and if they occur anywhere else in a program segment resident within the processing environment then clearly those exact assembler instructions show an attacking scraper.

 I am not describing anything new. Yet, the payment services industry continually lament the attack on payment data, know that retailers will be apathetic about the attack on payment data (because it only hurts their bottom line if they change their practices), and instead of protecting the vulnerable temporary holding areas, add increased protections to the tokens originating the data.

Why then force retailers to buy expensive new equipment? Good salesmanship, because it has nothing whatsoever to do with logic. What will happen this coming December? New scraper attacks will dominate the headlines, screaming banshees will claim the attacks occur because of the originating token, and then everything will settle back to normal and the most apathetic industry in the world will do absolutely nothing except collect fees for twiddling their collective thumbs. 

Next Blog: Lean and mean payment origination machines in web sites

Payment Guarantees

The payment services industry as a whole is not a very imaginative sector. It is a shame actually because there are some extraordinary talented people working diligently and never lifting the heads up to question the silly ideas about increasing moribund profits. Payment service executives fought tooth, claw, and wallet to protect the sacred interchange fee, without seeing that retailers begged for increased services. Retailers routinely sue the big payment networks, because the relationship, which at first was mutually beneficial, now is a mud fight inviting the oppressive hand of regulators to separate the combatants by force.

 So, I thought, heck, I can come up with some ideas that will increase payment system profits, and make retailers happy again.

1. Instead of a chargeback, offer no chargeback
2. Instead of fees for non-EMV conversion, sell secure payment system operating systems
3. Instead of batch submissions, give a real time approval and guarantee for type X100 messages
4. Offer private label card processing
5. Offer guarantees for international authorizations
6. Offer immediate transfer of tax receipts to tax recipients
7. Rent a bug to private labels
8. Talk to your customers and create products they demand, instead of saying pay me more for less service.

See, that wasn't hard, just put down your six shooters and have a cup of coffee with your old friends instead.

Next Blog: War and the Payment Hub

Attack Agents

This is the second and last blog specifically for fraud investigators detecting attacks on needs based payment system. I do not like to address one specific audience or one specific type of attack in this series of blogs because I like sleeping attackers. However, “no-seeums” prevalence within the needs based payment infrastructure requires special attention and I’m a special kind of guy.

I define the “no-seeums” attack as an attack on a payment system that investigators do not detect. Good folk recognize typical attacks on payment systems because other good folk report the attacks. No one ever reports a “no-seeums” attack because the victim is not party to the transaction. The only way to detect a “no-seeums” attack is with a behavior filter.

The most common “no-seeums” attack for needs based payment system is the false retailer. False retailers claim funds by presenting themselves as part of a large settlement stream to national retailers. In the SNAP community the behavior detection filter for this attack relies on STARS data collected by FNS. However, deploying a behavior detection filter for “no-seeums” without an evasion detection filter will do more harm than good.

Next Blog: Will hybrid payment settlement suffice for the bum’s pocket?

Detection of SNAP fraud in an EBT Environment

Fraud originating with EBT cards differs drastically in appearance than fraud originating from commercial cards. The reason for this dramatic difference is simple enough, EBT fraud origin requires collusion between the cardholder and the retailer (vendor in the SNAP world, but for the purposes of this blog, retailer). This allows fraud investigators to use EBT data to present a prima facie case to a judge that the intent and the action show a criminal act. It’s a pity that investigators do not use this most remarkable aspect of needs based payment data to track extremely vicious and powerful criminals.

I suspect the reason we do not use the data has nothing to do with malicious or planned practices, and everything to do with the difficulties of collection of data to present a prima facie case. Different vendors (sellers of goods and services, not retailers) possess the data. However all of the data regardless of the holder actually belongs to the administrators of the SNAP program and therefore shipped routinely to FNS.

I have developed a theory of fraud detection for needs based payment environment that I call behavior detection and evasion detection (BD/ED or conveniently enough Bad Ed). Subsequently I showed (at least to myself) that Bad Ed works well in other types of payment environments.  Bad Ed provides prima facie evidence for SNAP investigators because the data within the X9.58 message coupled with data from points of presence (POP) shows commission of a crime. For example, if the transaction originates from a place other than where the retailer conducts business then it is a crime and the data from a single transaction will show that.

The other aspect of Bad Ed, the evasion detection filter, requires that investigators construct it before deploying the behavior detection filter. Evasion detection works because criminals run after exposure of an attack method from behavior detection filter; they use another method, which exposes the new attack and gives foundation for the construction of a new behavior detection filter.

Next Blog: Will hybrid payment settlement suffice for the bum’s pocket?

Detection of Data Scraping in the Retail Payment Environment

Data scraping is software. As such it takes time to execute and that activity should be recognizable in a known processing environment. If retail payment system software does not check the validity of each interrupt vector periodically, then the risk for interception of payer data increases. If retail payment system software does not periodically examine software present in memory then the risk for interception of payer data increases. If retail payment system software does not check that the movement of payment data occurs within reasonable time then the risk for interception of payer data increases.

Checks required for payment operating systems in a retail environment need periodic examination to determine its effectiveness against current attacks. Anti-virus software works against known viruses and that is sufficient for processing of non-payment data. Processing payment data requires more control at the machine level. Ideally payment data moves within a limited processing area, configured precisely for the specific operational environment. There are no open ports not used for movement of payment data, there are no applications for humans other than monitors and no ability to access program or memory space in use by another application.

I think it is time the payment services industry defined precisely the functions of retail payment operating systems for web and traditional retailers. We may accomplish this many ways, either by fiat from the big payment networks or by including a host of industries to create an international standard. However, leaving the security of payment data to the whims of retail application developers is disastrous. It is time for a change. Use of generic operating systems to process financial data is simply too vulnerable to attacks.

Next Blog:?

The Payment Services Industry’s Pathetic Response to Criminal Attacks

Recently we have heard of some great successes with international arrests of alleged perpetrators of criminal attacks on our retail payment systems (See https://www.linkedin.com/today/post/article/20140723184327-606637-fighting-cybercrime-with-cooperation?trk=object-title  for example). While coordinated arrests and prosecutions are a minimum response, it is not sufficient to protect an industry bleeding Regulation E payouts.

The Payment Card Industry (PCI) data security standard (DSS) 

(https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf) while presenting quaint methods to protect  small businesses from hack attacks does not go far enough to protect payer data interception from the point of sale in the retail lane to an acquiring node or point of presence. Retailers deploy payment system equipment known to have vulnerabilities to unsophisticated attacks within this hazardous real estate and all the standard requires is to make sure payment equipment operates behind firewalls and owners catalog their software running on this equipment. The DSS does have other requirements, and in some cases mandates independent inspections, but it does not catalog the type of common attacks against the origination of payment data and makes no suggestions for defense of the type of attacks used against specific payment environments.

I recently wrote about two methods for detecting attacks in retail payment settings that use the relatively static memory environment of some equipment or that recognize increased changes in response time within the attack zone.  There are thousands of other approaches to detect an attacker presence, and yet the DSS remains mute on the topic. When I watch the airline industry respond to accidents or criminal attacks, I wonder why the payment industry does not attempt to prevent harm equally as well. Yet we plan to spend billions of dollars implanting EMV, which addresses less than half the type of attacks the payment industry experiences. What are we, nuts!

Next Blog: The three stooges

A Vision of Money in the Next Generation

I want to use the virtual bum’s pocket (VBP) small value gross retail payment system (SVGRTP) to construct a possible retail payment system in a future time. (The model is defined in http://paymentnetworks.blogspot.com/2014/07/indian-tribal-organizations-as-model.html and explored a bit more in a few blogs that follow it).

Our wallets in 30 years will never be inside a pocket or a purse. Our wallets will be in our phones, our watches, our glasses, and our gloves. For the purposes of this blog, the VBP spread to every corner of Earth. Whole industries issue currency without fear of antitrust complaints. For example the travel industry has one currency universally accepted by many small towns, by casinos, by ski resorts, and by car rental agencies.

Attackers swarm trying to capture the data flow between personal electronic devices and the entry points of presence (POP). Fake POPs routinely fool cheap wallets built to protect fast food and convenience store purchases. Attackers divert coins that buyers thought were on their way to purchase native arts and crafts, but wind up purchasing a turn of a roulette wheel on some distant shore instead.

The insurance industry captures perpetrators and recovers losses with sneaky code such as turning on the insurance tracker for all coins stored in its wallet. Scammers wind up mostly with revoked coins, worthless almost everywhere. Insurance only pays after an issuing payment hub pays consumer redemption of stolen or compromised currency.  Consumers do not know that their purchase did anything other than make the desired purchase. Crime novels describe sophisticated attacks and Hollywood makes the plots blockbusters. However, currency insurance rates remain low.

The drop in the cost of payment acceptance has a benign effect on worldwide trade. Ridiculous fees disappear (such as card not present (CNP) surcharges regardless if the buyer must appear and show government issued ID to complete a purchase). Insurance costs reflect real risk. Industries use a perpetual pool of cash float to grow and establish reserves at new hubs with common consumers.

New governments establish currencies quickly and use independent highly rated insurance to establish universal acceptance and meet the critical needs of its constituents. The need for International oversight of loaned money diminishes drastically as loans create the reserves of currency and the new government can show instantly the aggregate values outstanding and to some extent the physical location of circulating currency. Schoolchildren can independently verify their government’s accounting.

Underground economies grow and shrink according to the definition of contraband by their hosting country. Too many banned goods or services results in the growth of issuing hubs that rely on thugs for its protection, diminishing tax revenues, and increasing insurance costs for government issued currency.

All government policy results in increased or decreased tax revenues from payment hubs. Too many wars increase the cost of payments in real time, reducing velocity, and causing people to reflect on current government activity.   

Next Blog: Protection for retail payment hub misuse

Camouflage

The last two blogs discussed attacks and one approach for determining adequate defense expenditure. We already know the thieves’ budget (see http://paymentnetworks.blogspot.com/2014/05/security-and-payment-hubs.html ).  The last blog peeked at low hanging fruit by examining one way to increase throughput by reducing gates (creating a html tag based standard for data transmission from personal electronic device to a secure point of presence shares the cost across all segments of the payment data transport industry,  just saying). Now, I want to address a method of attack within the taxonomy of attacks (namely intercept of payer data) that also seems like a good place to spend defense dollars. I want to address what I call a camouflage attack.

I think a definition is on order. For the purposes of this blog a camouflage attack is unauthorized data residing within a payment hub used to intercept payer data. To determine the presence of the attack I created data radar.  Let M be a known static area of memory within a payment hub and J be a bit mask image taken of M within a Time T. I can then express a bogie (B) on the radar as:

And if B > | J | + ∆ its time to alert a human, STAT!

Next Blog: A General Defensive Budget

Catalog of Attacks on Retail Payment Hubs Continued

In the last blog, I unilaterally declared (without any evidence to back me up) that intercept of payer data posed the greatest vulnerability to payment hubs generally. I decided to show the attacking environment generally and show why I think so.

In two earlier blogs (see http://paymentnetworks.blogspot.com/2014/07/turnstiles.html  and http://paymentnetworks.blogspot.com/2014/07/payment-systems-of-underground-economies.html ), I showed how the construction of valves and turnstiles within payment clearing nodes decreased throughput of clearing flow. I want to further define these elements generally as gates and state a general relationship that where gates are present points of intercept (POI) are also present. I define a point of intercept as processing environment that single threads transaction data thereby potentially forming queues. I define queues as collection of data waiting for processing.

Given these definitions Diagram 24 shows the relationship as time passes.

Diagram 24 POI within Retail Clearing Systems

Diagram 25 shows that as processing delays increase data queues increase exponentially exposing transaction data to intercept for greater time. Emphasizing that I have no data to make this conjecture and that the relationship will actually be something different, I still conjecture that the relationship exists and looks similar to data displayed in Diagram 25.

Diagram 25: Relationship between Gates and Transaction Data in Queues

So, expenditure for defense may come in the form of decreasing gates.

Next Blog: Catalog of Attacks Final Blog

Catalog of Attacks on Retail Payment Hubs

I want to focus on materialistic outside attacks of payment conveyance mechanisms because regardless of the design of a payment hub, attacks will occur and some will succeed.  There are two types of attacks: attacks derived from intercepted payment data, or attacks derived from manufactured data. Except in the extraordinary case where manufactured data is the same as legitimate data (in which case it is the same as intercepted data), real time validation of some transaction data should detect manufactured data before payee acceptance. Transaction data critical to successful completion includes:

• Payer Data (Account Linked)
• Payee Data (Account Linked)
• Amount
• Date, Time
• Location of payer

The manufacture of Payee data does not accomplish an attack; it will create a failed transaction. The intercept and substitution of payee data can lead to a successful attack; however funds are recoverable if the original payee detects and reports the loss before the attacker escapes. The small value gross real time payment (SVGRTP) such as the virtual bum’s pocket (described in earlier blogs) virtually eliminates this type of attack because the payee anticipates the push of funds. The time for escape will be minimal because the payer will see the value removed from an associated account, from the notification of the removal, however the payee will not have notification of funds receipt. The funds become immediately recoverable after successful revocation of the currency certificate. However the next intended payee of the attacker must validate the certificate or the attack will succeed.

The manufacture of payer data can lead to a successful attack and payee loss. The authentication of the originator offers no defense. If the payer data does not receive validation before the payee receives notification of funds receipt the attack will succeed. Since the payer data does not actually link to an account, the attack fails if notification to payee does not occur until removal of funds from a payer account. Also if delivery of goods or services only occurs after a delay then the attack likely fails proportionally to the length of the delay.

Intercept of payer data can lead to a successful attack. With absolutely no data to back me up, I want to say the greatest vulnerability of all retail payment systems is the intercept of payer data. If true, then the attack deserves the greatest resources for defense. I described in earlier blog that one defense against the attack is to validate that the distance and time from the last transaction is possible. However, once a payment hub deploys that defense, attackers defeat it by substituting the new location details to meet the possibility criteria. Authentication of the user does not prevent interception of user data. Authentication of the electronic device (if used to originate a transaction) seems to give the greatest consistent defense against intercepted payer data use in a transaction. For example if the currency described for use by the virtual bum’s pocket is registered by an insurance company as residing in a specific device, then that specific device must be able to provide a certificate showing it is the device known to the insurer without repudiation.   Generally, validating that the payment hub “knows” an initiating device, works against attackers using intercepted payer data, especially if the device is unique to the payer. In other words using a cell phone to initiate a payment may provide greater defense than a common device such as a point of sale card acceptance device used by the public at large.

Next Blog: Continued taxonomy of attacks

Defining Risk for Retail Payment Hubs

We now have in hand a currency, a payment hub, and a design for connectivity. These are products of my imagination, but useful to consider a specific element of retail payment system risk.

I define risk as the value of a payment hub at an instant in time. I assign the symbol M to designate this value and

M = Onus + Onyou + Dv/Dt

Where Onus = value of payment hub funds on deposit

            Onyou = value of other payment hub funds on deposit

And     Dv/Dt = net velocity of payment flow value.

There are some unusual characteristics of M because anecdotally it appears that as it gets larger, its vulnerability changes. Wholesale hubs seem almost immune to attacks motivated by material gain because it is impossible to hide one trillion dollars. However, the interruption of payment flow from a wholesale payment hub causes economic disruption felt by all governments on the planet. Systemic failure of a wholesale payment hub has never happened but the consequences of such a failure will be severe.

Failure of a retail payment hub may cause local economic pain and the size of M is predictive of the economic shrinkage resulting from a failure. However seldom will the failure of a retail payment hub cause the collapse of a government. Typically insurance prevents the failure of a retail payment hub from a materialistic attack. It is the risk, M, of a retail payment hub, and the vulnerability to a materialistic attack I examined in this blog.  Materialistic attacks from outside a payment hub occur mostly on the dv/dt portion of M and so velocity value defines insurable risk for the purposes of this blog. It’s not that the Bernie Madoffs do not exist and that retail payment hubs are not vulnerable to a Madoff type risk; however, I want to design a retail payment hub that reduces the vulnerability of dv/dt to materialistic attack.

In the aggregate the US retail payment hubs moved US $79 Trillion in funds and suffered $8 Billion in losses due to materialistic attacks. So dv/dt = 79 Trillion/365 = $2,505,073.57 per second losing $253.68 to materialistic attacks or about .01%. That number however does not give the true story. There are two elements to one type of successful electronic attack:  intercept of transaction data, and use of the intercepted data for unauthorized transactions. The only other method of attack is to manufacture transaction data.  It is impossible to tell what the potential value of intercepted financial data is, or if a relationship exists between potential value of intercepted data and value of unauthorized use except to say anecdotally use seems to be a lot less than potential value intercepted. Regardless of the defensive posture of our payment hub we know that any tax on the funds for defensive mechanisms cannot exceed .01% of dv/dt because then we would spend more than we lose.

Next Blog: Spending Defensive Funds on the Model System

Attack on the Virtual Bum’s Pocket

All the virtual bum’s pockets (VBP) come equipped with an audit scope. The scope is a web page that came as standard equipment in the software development kit. The designers created the scope originally for bankers only to examine the internal activity of a potential or operational partner, but its early implementation had a buggy verification mechanism, and since the scope only displays aggregate data and no instructions could flow down from the port, most VBP operators turned off the “validation required” setting (acting against the advice of Treasury security people).

I pointed my browser to the audit scope page and received the first page of the site that contained all the information I needed for a successful attack. Diagram 23 depicts the landing page of a standard virtual bum’s pocket audit scope.

Diagram 23 VBP Standard Starting Dashboard

It was the perfect size. The Galactic Bank like other astronomical financial institutions seldom validated a deposit in the form of a VBP currency in real time because of the drag on throughput. If they actually attempted to validate the currency and had a delayed response of over a few hundred milliseconds, validation just did not happen.  At least I was counting on lax security, especially since I was going to make the deposit at rush hour.

I spent the next few days recording purchases at the bars, restaurants, and grocery stores around town and copied the certificate and inferred the serial numbers for the entire circulation. Once again, these yahoos ignored the warnings of security experts and issued all their currency with sequential security numbers. It felt like taking candy from a baby.

I bought the tool to manufacture a unit of currency and created one in the mid range of the serial numbers. I made it for a few pythons less than the entire circulation amount so it would not attract undue attention. I took the coin to a close (about 50 light years) Galactic branch, beamed it to the change machine, and I now am writing this blog in a Styngyn jail cell. The yahoos did follow one procedure, they pinged their currency every 2 seconds, found my coin (required to respond when pinged) and revoked all their certificates through a dedicated link for the banking network.

Next Blog: Less fiction. 

Designer Currency for the Modern Bum’s Pocket

In the last blog I started an attack plan against the currency issued by nodes connected together by a common settlement system (SVGRTP) and issuing their own separate currencies. My proposed victim operates in a small region on the planet Federalia in the northeast quadrant of the cluster Globulus. The connected network of Virtual Bum’s Pockets (VBP) primarily settles a local poker game for a few hundred Federalia schniztals every weekend but many of the small shops, bars, and one of the larger food chains also accept the currency. Turnover is steady at almost 10,000 schniztals every week. All currency issued from any VBP have the same structure shown in Diagram 22.

Diagram 22 Currency and its controlling mechanism

I signed the diagram, dear reader(s) to emphasize a point. Send the diagram back to me and claim it is yours. I will buy you a beer if you can prove, using the signature, that the diagram comes from you. On second thought if you can do that, I will buy you dinner and 2 beers, or coffee if you don’t drink alcohol. The point is dear reader(s), I am not attacking the certificates. You might have a good plan for doing so, send your comments or write directly on the blog about how to do it. I, however, am a lazy crook, and want to probe the weaker parts.

I do not want to attack the currency if the issuer did not fully implement all its controls. There simply is not enough money in it, or if there is, I really do not want to mess with that issuer. I want to attack the timing of the verification controls. If I can hit all the currency in circulation at the right time, I might capture all of it and present it to a remote collection point far from the planet, change the currency into a widely circulated one, and disappear. Verification depends on its I/O, the weak link in the chain.

Attacking the region’s power supply will not work; most of the points of presence (POP), have independent power supply and there are thousands of POPs in the 50 square mile main acceptance region. I plan to jam the planet’s communications with the galactic net so the local currency traffic does not interact with wide circulation for at least 5 seconds. Great, I have a method for attack and a window of opportunity.  

Next Blog: Our young hero buys the equipment to implement the attack.

Vulnerability and Risk for the Model Payment System

Once finishing the sketch of a design for a payment system (See last 3 blogs), I can do what I never get to do in public with a real system. I get to publically expose its risks, and not just the boring risks wholesale bankers discuss, namely liquidity, credit, systemic, operational, and legal, but the vulnerability to planned attacks, and the validity of funds spent for defense, and insurance against attacks.

An astute observer may note that the difference between wholesale and retail payment hubs is value. Speaking from memory, retail payment system value in 2012 was $79 Trillion, while wholesale payment value for that year was $750 Trillion 

(See http://www.frbservices.org/files/communications/pdf/research/2013_payments_study_summary.pdf  and data at http://www.federalreserve.gov/paymentsystems/fedfunds_ann.htm for actual numbers including definitions and assumptions),

Since aggregate retail payments have about 1/10^th the value as wholesale payments, the risk of loss has the same decrease in value. Further all the boring risks wholesale payments system managers spend fussing over do not really affect retail payment systems as much because if you knock out one player, the boat still floats if it is a healthy, evolving and growing system and has meaningful rules. Rules are important; but, I can say from the bottom of my heart that there are people within the payment system industry that know a lot more about writing rules than me, I want to attack.  

Besides, it is not the rules governing the model system; I plan to build a public access audit port to (SVGRTP) hubs.  This multi-function inspection probe with public access mitigates risks or at least allows potential partners to monitor the real risks of partner or potential partner payment hubs, but I wanted to take time here to attack it, not protect it.

I name the model under investigation the Virtual Bum’s Pocket (VBP); it is the SVGRTP discussed in the last 3 blogs. VBP hubs issue virtual currency and so a time tested attack is to manufacture value and introduce it from an unauthorized source. Certainly, this is a prime avenue for an attack. The currency design is the prime defense against counterfeiting. The currency has 3 protections against its counterfeiting, namely:

• Non-revocable doubly signed certificates
• Responds to “page”
• Insurance

The Europay MasterCard VISA (EMV) specifications (particularly volume 2, see http://www.emvco.com/specifications.aspx?id=223 ) adequately describe implementing signed certificates. Two other elements make currency attack difficult. The currency if placed in specially designed containers respond to a page requests. The issuer sends a request for the currency to give its location and if it resides in an authorized container communicating with the world at large it responds. The issuer can revoke it if the currency does not respond by a time specified by the issuer. If the currency issuer opted for insurance, the insurance company may imbed tracking controls within the currency data. Those tracking controls known only to the insurance company contain a wide array of constantly evolving defenses.

I now have the defenses in place. I will implement my attack tomorrow. Moo ha ha.

Next Blog: In which our young hero, attacks the bum’s pocket with stone knives and bearskins

Connecting the Payment Modules Together

Our small value gross real time payment system (SVGRTP) now has form, and some functions, and some controls. Yet, the real reason for the design was the ability for its implementers to connect with like payment hubs. For example a national retailer hooks into the Indian Tribal Organization SVGRTP, then, they can exchange virtual currency between them in real time, swap their retailer databases so their retailers can accept the same currency, thereby reducing bank card network fees while growing their customer base. Diagram 20 shows connected SVGRTP

Diagram 20 Connected SVRTP

The configuration becomes infinitely scalable as shown in diagram 21

Diagram 21 Growth of SVGRTP

The design is complete, however, the devil in any such undertaking, is always in the details. The design gives a unique risk profile. I will explore that risk profile in the next several blogs.

Next Blog: Introducing the Concept of Pressure