With Web services, many industries, including insurance, are looking to realize their vision of virtual systems that locate, configure and invoke business services over the Web just as easily as they do internally within their own application portfolios.
For example, an insurance carrier with a disability line of insurance might be able to easily calculate gross indemnity benefits with their in-house system. Yet that same firm may have a challenge calculating and withholding federal, state, FICA and local taxes on payments. Wouldn't it be ideal to use a common application for the calculation easily accessible via the Internet?
Web-service standards are maturing to the point where this ideal is technically feasible, albeit in embryonic form. However, there are significant business and compliance concerns with this utopian use of Web services.
Using the disability payment tax calculation example, there are still thorny questions to be answered. They include:
- Are the tax calculations acceptable to the Internal Revenue Service?
- What assurances are there that the calculations are consistently accurate?
- What recourse is available if they are wrong?
- Is compliance guaranteed and does the service provider have sufficient and auditable controls?
- Does the Web service behave as advertised?
The biggest fly in the ointment can be found in the compliance requirements dictated by the Sarbanes-Oxley Act. Mention "compliance" to today's insurance executive, and you're sure to conjure vivid images of scandal-plagued companies such as Enron, WorldCom and Tyco.
Insurance executives, in particular chief financial officers, are looking to their accountants and auditors now more than ever to keep the company on the straight and narrow--and to keep themselves out of the clink. They also depend on chief information officers and application developers to create system monitors that oversee key business processes and better automate corporate governance.
The SOX-compliance challenge is tough enough when an insurer's accountants and auditors are working with their own internal systems. But imagine orchestrating the same levels of control, security and reporting when relying on external Web services. Does this concern mean Web services should be abandoned? Not at all, but these technologies need to be selectively and judiciously put into practice.
COMPLIANCE: SOX AND MAR
Two compliance laws have a direct impact on insurers and their use of Web services. They are the Public Company Accounting Reform and Investor Protection Act of 2002, also known as the Sarbanes-Oxley Act, and the National Association of Insurance Commissioners' Model Audit Rule recommendations. Both of these grew out of the recent tidal wave of corporate scandals resulting in the call to improve controls in corporate America.
The provisions of SOX have been a heavy burden on internal audit and information technology departments of public companies, with Section 404 mandating internal controls be fully documented and regularly tested for all systems that produce or affect the financials of a company. Nor is SOX a one-time event, with companies duty-bound to concentrate on ongoing compliance and regular testing.
Insurance companies--including mutuals--that are currently exempt from SOX have enjoyed only a temporary respite, as the NAIC has almost finalized revisions to MAR that embrace most of the SOX provisions. The NAIC has every intention of making these provisions mandatory for all insurance companies with a direct written premium greater than $50 million.
Emerging Web services will prove to be a particularly vexing issue in the years ahead for those responsible for SOX or MAR compliance.
Web services must be compliant when processing or affecting the financials for a company. They must be fully documented and the internal controls described in detail. There also must be a method for regularly testing controls to ensure ongoing compliance.
Web services are typically published using a Universal Description, Discovery and Integration directory; a kind of "telephone directory" of Web services. The UDDI specification continues to mature with new features to ensure only authorized parties can modify and update entries in UDDI directories. While these pragmatic improvements are encouraging, UDDI directories cannot be burdened with describing and implementing all the controls demanded by SOX and MAR compliance.
As a result, Web services in the public domain are gaining little traction other than for trivial services. No responsible auditor or financial officer will accept the notion of a virtual system that dynamically locates, configures and invokes business services over the Web and accepts the public UDDI entries at face value.
How then can companies embrace Web services and other outsourcing models while satisfying corporate financial governance that seemingly gets tighter with each new piece of legislation?
PUBLIC OR PRIVATE DOMAINS?
Mission-critical Web services, with material bearing on a company's financials, demand trusted partner relationships with acceptable controls. These trusted partners must be able to demonstrate full SOX compliance. The issue is not confined to the Web services, but applies equally to other popular outsourcing arrangements, including hybrid Web services employed by application service providers and business-process outsourcing providers.
Public-domain Web services are open to abuse and attack from almost every quarter, and are inherently more risky than those hosted in private domains.
Private domains make use of private peer-to-peer network connections between trusted business partners. By definition private domains are not anonymous, offering peer-to-peer connections while still utilizing the Web infrastructure to offer a good compromise.
Great strides have been made in Web-services security, although there are still major challenges around organizing security models across disparate organizations. Companies that opt to use Internet connections must thoroughly address authorization and authentication issues.
Highly recommended is the use of a contractual service-level agreement that specifies the levels of service expected, change control procedures and remediation processes.
Web-service purists may feel that such recommendations compromise dynamic services in an open-bidding marketplace, but this does not significantly inhibit companies opting for service providers that implement industry standards.
CERTIFICATIONS AND CONTROLS
In order to ensure Web-service baseline documentation and process controls, it is reasonable to demand minimum standards be followed by external service providers such as outlined by the American Institute of Certified Public Accountants' statement on Auditing Standards for Service Organizations. This certification requires a service provider to have an in-depth independent audit of control activities, including information technology and related processes.
Also helpful is ISO 9000 certification, which provides assurances for consistent processes and also baseline processes in terms of inputs, outputs, transformations and related controls.
Active use and full testing of Web-service controls should be conducted on a scheduled basis. Controls should be tested for standard usage. It is advisable to intentionally compromise the test to ensure the controls and standards hold up against the worst of conditions--from bad data to outright abuse.
Web services offer the most structured and standardized interoperability model available between disparate systems. However, strict SOX- and NAIC-compliance requirements and risk assessment will confine Web services (at least those that have an impact on a company's financials) to the private or trusted partnership domains for the foreseeable future.
Best practices are still emerging around Web services and have a way to go to fully support today's complex SOX-compliance standards.
Companies should tread lightly as they venture into the Web-services world with their eyes wide open and with a thorough understanding of the limitations, issues and implementation options.
RODNEY GRIFFIN is an executive with InsureWorx, a software vendor.
August 1, 2005
Copyright 2005© LRP Publications