Inter-BSP transaction batch submission

Posted: Fri, May 19, 2000 at 19:57:58 (EDT)

Subject: Re: Security for ASPs

Posted by: Todd Boyle

Message: BSPs should submit transactions to each other and to the General Ledger
as unposted tranasaction batches rather than slamming them straight into the
destination system in ways the user cannot verify.

Realtime interfacing is definitely happening in 2Q2000, for particular functions. For example webstores are interfacing inventory realtime, allover the internet and EBPP billing and other payments services are getting integrated, sporadically with subscribers' accounting systems. I seem to recall there are over a million people doing bill payment on Quicken/Intuit website alone.

I think the broader market of BSPs should plan on realtime interfaces in the next 12-24 months, and that they will be based on middleware (MQ Series, Extricity, Netfish, webmethods, there are fifty of these server platforms)

BSPS should go forward at full speed, with XML based transaction batches anticipating those interfaces. smbXML is a great place to start. You can build most of your platform without any real delivery platform, by storing transaction batches in XML.

The principle of reviewing and approving batches manually can be applied by users to *any kind of batch* that has arrived at their general ledger, without incurring much additional work. Account balance and inventory counts can be allowed to run ahead unapproved for certain purposes, which supports your interface to 3rd parties for realtime commerce without much risk of theft.

Most of my clients are comfortable enough today, with the completely insecure postal mail in which they might receive bills from a perfect stranger, any time. They just throw away such bills. All SMEs are like this. They know their own business!

What they need is the tools to review detailed reports to their hearts' content on the originating BSP, including aggregates or totals, in a way that facilitates their approving them or posting them later, into the destination system. Here are design suggestions: http://www.gldialtone.com/A2AforBSPs.htm#levels

3rd party e-services are emerging -- transaction archives, internal control monitoring firms, etc.- and temporary data stores. Just as EAI vendors provide a 'Hub' that saves each party from maintaining N-squared interfaces, temporary hosts would enable users to stuff their XML batches onto the hub, and exit from the originating BSP service. Then they would login to their general ledger service (or other destination) and query the 'Hub' for all their batches.

The key to subscriber acceptance of workarounds based on batch approvals is control totals and planning and testing... an attractive facility including printouts should be designed for any economic event on your BSP that needs to be transferred into another BSP or local system. The subscriber needs to have the confidence the total batch hangs together, without checking every line. Tutorials and training should be provided to coach the subscriber how to keypunch or upload economic events into your BSP screens based on events coming from elsewhere, and reports with month-to-date totals before and after all data entry processes are required to help the user check the BSP's recordkeeping (yes- small businesses do check.)

I'm sure this 'batch' discussion sounds retro to some people. It is contrary to my utopian vision of single-signon and seamless integration! But it also provides subscribers with a sense of confidence in the system. Owners of companies are always going to review their transactions one way or another. What you want to do is design reports that they would want to review anyway, to manage their business, while making these reports serve as the reviews of batches crossing the border between their providers.

BSPs who integrate directly with other services, providing a single-signon or seamless connection, need *very* good network security engineers. But the BSPs don't recognize they also need some crusty old accounting and banking types of auditors to grub around and look at all the procedures, permissions and separations of duties at the BSPs. And that they will then enforce procedures. This will not really be a big deal. It will however, not be fun. It takes a lot of the fun out of being the chief developer, or sysadmin. Suddenly you're a bank, not a dotcom.

Todd Boyle CPA www.gldialtone.com/webledger.htm