o say that what goes around comes around is hardly novel or original. Yet I see the inception of the Visa POS check program as bringing us full circle. But first let me clear up more than a few misconceptions regarding Visa POS.

Given: The Visa POS check program was created to take advantage of the fact that existing Visa member institutions also have a base of demand deposit holders against which existing paper check transactions could be electronically converted and ultimately debited like a Visa "check card" but without necessity of the plastic medium.

Moreover, Visa network bandwidth for authorization and settlement easily can accommodate substantial additional transaction traffic over the existing infrastructure.

The Cast of Characters: Participating member Visa financial institutions, merchant acquirers, third-party authorizers and participating merchants.

Let's create some basic definitions so that we are all on the same page. After all, I personally have heard some incredibly off-the-wall interpretations of what the Visa POS check program is all about.

My guess is that if I were to talk to 100 different ISOs and acquirers I would get 90 different interpretations. So in the interest of science and humanity, here goes nothing!

1. "Participating banks" are those Visa member financial institutions that have contracted with Visa to accept authorization inquiries for checks drawn on themselves and presented to participating merchants for which the bank will provide one of three possible services: (a) conversion only, (b) conversion with verification or (c) conversion with guarantee.

2. "Third-party authorizers" are those processing entities that have contracted with Visa and merchant acquiring partners to accept authorization inquiries for checks drawn on a non-participating bank and presented to merchants for which the third party will provide one of three possible services: (a) conversion only, (b) conversion with verification or (c) conversion with guarantee.

3. A merchant bankcard acquirer will establish the relationship between itself and the merchant and will contract with a third-party authorizer for the handling of all non-participating transactions.

4. A third-party authorizer will create a transaction fee/tiered buy rate pricing structure that a merchant acquirer essentially will treat as its "interchange" cost.

5. A merchant acquirer will (a) establish a "retail" transaction fee or (b) a "retail" discount rate if guarantee is involved or (c) a combination of the above based upon its wholesale cost structure, which is defined as its backroom authorization and settlement processing overhead, participating bank transaction interchange as well as the stated third-party interchange expense.

6. A third-party authorizer (which by coincidence also can be an acquirer) will debit the check writer via the ACH and then subsequently transmit such information to the partnering merchant acquirer that then creates daily integrated "Visa POS check" settlement for the merchant by means of the existing Visa settlement process.

   The acquirer then can report such data by either (a) a single merchant month-end statement delineating bankcard batches/settlement and Visa POS batches/settlement or (b) two month-end statements where one statement represents bankcard volume/settlement and the other identifies check-related Visa POS volume/settlement.

7. A participating merchant should see the authorization as a seamless process in that VisaNet will be switching the transaction requests to the appropriate party (the participating bank or the third-party authorizer). Terminal behavior/prompting is the same in either case given one uniform terminal processing specification was given to all participating processors. A merchant does not know and should not care whether a given transaction is participating or not; authorizations, reporting and settlement behavior are the same in all instances.

1. Conversion Only - A participating bank validates an account as being "live" though a third party may or may not do account validation (transaction fee).
2. Conversion with Verification - A participating bank validates an account as being "live" as well as funds present. A third party may or may not do account validation and likely will check against national/regional/proprietary negative files (transaction fee).
3. Conversion with Guarantee - A participating bank or a third party also will assume the risk in the event the electronic debit fails to post (discount plus transaction fee).

So if this all sounds too good to be true, then why the delays in ramping up the program?

First, so that the merchant sees integrated batch data, merchant bankcard acquirers need to write a lot of code to integrate third-party transaction/settlement/chargeback data as well as the participating bank transactions into their own legacy authorization, settlement and accounting systems.

Second, you need participating banks, otherwise the batch data only would encompass transactions authorized by the third party; or, looking at it another way, it would be the equivalent of what already occurs today in a traditional check conversion transaction, yet without Visa POS.

Unfortunately, participating banks also have code to write to determine which of the three service types described above applies to any given transaction and then perform the appropriate processing function, not the least of which includes taking risk on guarantee transactions.

And, finally, third-party authorizers have code to write, procedures to implement and processes to initiate:

• To receive and respond to transactions from a Visa Issuer Access Point.
• To determine which service feature is required for any given merchant.
• To debit consumer funds via the ACH.
• To partner with a merchant acquirer.
• To transmit daily files and fund the acquirer who in turn funds the merchant.
• If necessary, to charge back the acquirer given a rejected ACH entry for a non-guarantee transaction.

And the list goes on.

As is the case with NACHA point-of-purchase transactions, business checks cannot be run through the VisaNet third-party authorization system unless the third party cannot determine whether the check is a business check.

So for all those checking accounts whose MICR line begins with the check number, yep, they're out of luck - unless, of course, the third party has written a "work around" to split dial (directly to the third party without going through VisaNet) those types of checks.

Canadian checks have the same problem ... and yes, the same split-dial solution can apply. And while they are not "converted," they certainly can be verified or guaranteed depending on the option chosen.

Additionally, many of the third-party providers already up and operational on Visa POS do not support (a) magnetic swiping of a check writer's driver's license or (b) check imaging or (c) dealing with a "paper" check when the consumer refuses to sign the authorization receipt.

But, alas, those issues are easily fixed. At least within our company we've already addressed all these "opportunities" and more within our own set of proprietary terminal enhancements.

Perhaps the more interesting issue is pricing. And since the traditional interchange model is being used, let me offer up a few comments.

Given that participating bank interchange is currently fixed at 1.00% plus $.07 per transaction and third-party interchange can float based on the fee structure of the third party (typically based on four to six different interchange tiers depending on the merchant standard industry classification), the merchant acquirer must create a blended fee structure to generate ISO "buy rates."

However, as is the case with Visa debit, which recently has been the focus of a major re-engineering of its interchange basis, there are many industries whose existing return-check loss structure is much lower than the Visa POS 1.00% mandated participating bank interchange.

While I can cite grocery stores, convenience stores, fuel stations and auto dealers, to name just a few, many other industry types might find it difficult to embrace this increased cost basis without observing new cost-saving or revenue-generating program features.

Moreover, to create an appropriate blended rate the merchant acquirer might need to coerce the third-party authorizer to create an artificially low rate (and lose money) to offset the higher participating bank interchange rate. Somehow, I just don't think that dog will hunt.

On the other hand, if a merchant only uses the Visa POS guarantee feature for a given set of transactions that the merchant's internal policy or sophisticated server-based risk-management system defines as above average risk, then the 1.00% rate could be considered quite competitive.

But if that selection process is not determined in a transparent, automated fashion by an in-house computer system, then the merchant will need to train store personnel to select verification for some transactions and guarantee for others, according to prescribed store policy (a real-time process not normally seen today in the small-merchant environment). So, all in all, what do I think? Well, the burden of growth clearly swings on the addition of participating banks, so if Visa is successful in that channel then acquirers and third parties will over time slowly and surely come online in greater numbers.

Of particular note is that by definition increasing participating bank membership takes business away from third-party check companies!

Finally, please note the Catch-22: If participating bank interchange rates stay at the current 1.00% level (which is not the marked-up, final retail price of the acquirer or ISO), then, unless merchants opt to selectively guarantee the checks they accept, third-party check firms may have a material internal cost advantage that translates into lower direct prices to ISOs and merchants.

On the other hand, if participating bank interchange is reduced to create more attractive pricing for that set of merchants that chooses to guarantee all checks, then by definition a participating bank's appetite to perform guarantee may be equally reduced given its lowered revenue stream. All in all, it should be a good show!

To learn more about SPS, visit www.securepaymentsystems.com or e-mail Lin at lfellerman@securepaymentsystems.com