BSPs Self Regulation
|Posted: Sat, Mar 25, 2000 at 16:31:54 (EST)|
|Subject: Integration vs internal control|
|Posted by: Todd Boyle|
|Email Address: firstname.lastname@example.org|
One of the economic engines powering BSPs'
growth into SME markets is cost savings. Printing, postage, trips to the
bank, and most of all, bookkeeping and accounting busywork is being
automated out of the system.
It is becoming clear that ASPs and BSPs are developing XML interfaces among and between themselves (A2A Application to Application integration) as well as B2B interfaces which exchange purchase and sales with third parties.
These interfaces are designed to execute every type of transaction as expeditiously as possible. Each step in these business processes is coming under widespread scrutiny by web developers in each of the respective horizontal platforms.
The BSPs are exerting considerable will and resources to systematically mine and extract the labor and financial savings by efficient, tight integrations.
However, most BSPs do not realize the gravity or scope of the internal control risks that will emerge from this whole transaction fabric. For example, consider the case of three BSPs:
-- a purchasing website where subscribers incur Accounts Payable, for example, within some type of supply chain or vertical portal,
-- a general ledger (webledger) provider who maintains accounts payable and other basic infrastructure for subscribers, and
-- a financial institution who provides payment execution among other things.
You can see that *any* support tech. at *any* of the providers could potentially get ahold of a password and have more power than a bank clerk would have, knowing your ATM PIN.
Obviously, it is a big objective of everybody in the BSP marketplace to somehow create solutions that empower the subscriber to conduct business efficiently among scenarios like the above. Bear in mind that the subscriber will have several other BSPs such as payroll on the liability side, and others on the revenue side.
Any auditor can, within an afternoons' work, identify dozens and perhaps hundreds, of separate points in this architecture, where a bewildering variety of players could potentially steal money.
Each of those points will require a systematic evaluation of existing internal controls. The controls will include numerous security and technology reviews, including many which extend outside the website to encryption keys and providers, network providers etc. The controls will include careful consideration of the actual permissions and powers of every employee in each of the BSPs. The controls would be further complicated by privacy requirements.
When a webledger provider provides banking services, in effect there will not be any difference between books and bank. When a webledger provider provides integration between subscribers' Accounts Payable and their trading partners' Accounts Receivable, there will never be any differnces between those systems.
Do you see why this is categorically different from the internal control systems of the past? Accountants have no experience other than segregation of duties within the company. Even the decades of system experience by banking regulators leaves them unprepared for a situation where customers would be literally helpless to *detect* balance fraud because the subscribers' general ledger is automatically kept equal to the bank. There is no businessman in the world who runs a calculator over their bank statement nor should they: their general ledger will reveal differences. sheesh. there are too many scenarios to list.
There is an intrinsic, inverse relationship between greater integration, and internal control. Every point of excess labor, duplication or separation that is removed from a business process, usually removes certain components of internal control. (It also might remove certain risks.)
Any webledger that doesn't have payments-grade security should not be in business. Full, payments-grade security is a baseline requirement for a general ledger, because any thief who can get into your general ledger, AR, AP or inventory accounts, can convert some of it to cash.
There is far too little discussion and academic consideration of this problem between BSPs. You want efficiency, and you can save 10 million man-years every year by eliminating redudancy and duplication. To reach these savings, however, you need to develop a whole new set of internal control practices and methods. Those internal controls can be very largely automated and in any case will cost no more than 10 cents on the dollar, compared with the present brute force, manual reconciliation and standalone ledgers. But these new controls will definitely cost money.
The internet is so different that it requires a whole new intellectual effort. These internal control mechanisms will probably have to be achieved by yet another set of BSPs on the internet because they span enterprises. There are a number of ways the BSPs themselves could contract for internal control services thus segregating them completely out of their organizations. Remember this is not just a matter of TCP/IP and routers. Telcos and software companies are not going to be able to go into the XML traffic itself and apply a professional level of internal control logic. What's required is an intricate system for modelling the permissions of various parties, the presentments that have been verified via the subscribers' and reviewers' interface, etc. You need continual reviews, both detailed and aggregate totals.
Establishing a comprehensive conceptual framework for this security challenge will apparently take many years, if the present behavior of ASPs, BSPs and DotComs are any indication.
The employees in the DotComs who understand this problem cannot speak. They are all locked up by nondisclosures and forced by their CEOs to work on their own, or in tight partnerships. That's why the ASP consortium and the IBSI have been silent, since birth.
Most e-commerce sites won't contribute to a conceptual framework much less populate it with solutions because A) cost of articulating the framework, B) once built the framework would be a roadmap for newcomers into the market, C) CEOs know their security isn't ideal and don't want to provide a roadmap for crackers, D) developers know their security skills are not up to par, and don't want to discuss it at least until their options vest, and E) the large established providers have economic incentives not to assist internal control initiatives which empower the smaller BSP and DotCom providers. Security failures at the DotComs drive consumers back to closed, turnkey systems on private networks, systems which simply ignore open commerce or are locked into verticals, or back to standalone Midrange software maintained by VARs.
The intellectual and legal challenge of inter-ASP internal control will probably have to be addressed by the academic community or perhaps, government regulation.
What follows, is just some of my own ideas. If they're wrong nobody has ever bothered to respond and correct them (you can be the first).
The CPA industry has completely failed to address the need, within an acceptable value proposition. I point to the near zero market acceptance of the WebTrust services, for example. The cause of this failure is that AICPA is the only body that blesses CPAs and grants credibility, and it is run by the Big 5 firms. The Big 5 have the primary purpose of maximizing revenue within a constraint of small headcount. Since they cannot possibly deploy or manage large scale services to small business, their challenge is how to skim the top 5% of lucrative business that can be done by their few thousand professionals. Accordingly, all the rules in AICPA are tailored to that constraint. Thus, there will never be any common-sense web security certification from the CPA profession. The CPA industry is anyways, lacking in systems or security skills, or the personnel management skills to build up these resources.
I still hope the ASP Consortium or IBSI will rise to the challenge, at least with some white papers and some basic tests and certifications.
Perhaps IBSI could provide a meta-framework declaring the criteria for separate certifications, i.e. the IBSI Certificate will be issued if the BSP has 3 certifications:
- system security certifications, from Sun, HP, Cisco, or whatever,
- review of separation of duties and other controls by CPAs/PAs,
- review of __________ fill in your favorite topic, by banking regulators, BBB,
Perhaps the IBSI could set criteria for these certifications such as auditors should address XYZ types of risks, or they must be conducted within an ISO 9000 compliant process, etc.
pant pant. too much expresso again, at lunch,
Todd Boyle CPA www.gldialtone.com