Prudential's success in the variable annuity market is owed in large measure to the carrier's unique "highest daily" living benefits, which are elected on nearly 90 percent of its variable annuities. According to the company, the Highest Daily (HD) Lifetime Income benefit is the only benefit available that locks in the client's highest daily account value and continues to grow that amount at a 5 percent compounded annual rate until the client begins to take lifetime withdrawals. Prudential also guarantees a protected withdrawal value of at least double the account value if the benefit has been owned for at least 12 years.
According to Steven Marenakos, SVP of operations and technology for Prudential Annuities, the company is able to offer these guarantees by utilizing a risk management model driven by an algorithm that triggers the transfer of amounts within an annuity between equity-based investment portfolios and investment-grade bond funds, under certain conditions. The transfer into the more conservative bond funds limits an annuity holder's flexibility to control investments, he acknowledges, but end-customers and distributors have found protection from precipitous account value losses a satisfactory tradeoff, Marenakos insists. When markets recover, he explains, "You can move out of the bond funds very quickly and back into equity-based funds so that you enjoy the upside but you're backstopped on the downside."
Pushing the Limits
The success of Prudential's HD Lifetime living benefit, however, pushed the limits of the company's processing capacity. Prudential administers its entire book of annuity contracts on what Marenakos describes as a highly customized version of Atlanta-based McCamish's (now Bangalore-based Infosys) Variable Product Administrative System (VPAS) built on Progress Software's (Bedford, Mass.) OpenEdge development software. The system runs on IBM P6 servers running the AIX operating system. Administering HD Lifetime, Marenakos adds, requires core batch processing after every work day, followed by the creation of hedging input files, broker/dealer activity files and a netted position file, in order to deliver trades to portfolio managers.
In 2008, Marenakos relates, the market volatility associated with the financial crisis put more pressure on Prudential's systems because of the number of trades either made within equities or triggered by the algorithm to transfer into bond funds -- and back as market conditions improved. "It was further stressed in 2009 by the increasing sales of products that require daily algorithmic monitoring and trading," he notes. "The demands on our applications were rapidly increasing."
Between 2005 and 2010, the number of distributor firms doing business with Prudential electronically increased, as did the sizes of daily data transmissions to them, according to Marenakos. As a result, core batch run times increased by three hours.
"Early data delivery is a requirement to do business with the 'VIP' firms," explains Marenakos. "Demand for near-real-time actuarial data was increasing to perform the sophisticated financial risk management process to support our products."
By mid-2009, Marenakos says, it was evident that tactical Band-Aid solutions would be inadequate to meet the needs implied by Prudential's three- to five-year growth plans for annuities. At the time, Marenakos submitted a proposal to increase application capacity that was approved by senior management in October of that year. The goals of the initiative, he states, were to process more than 100,000 customer account transactions, associated with about 1.5 million annuities, in less than six hours; to deliver all e-commerce interfaces to internal and external business partners by 4 a.m. on all working days; and to achieve screen-to-screen response times for applications of less than two seconds with up to 2,000 concurrent users.
Prudential's most urgent challenge, according to Marenakos, was to compress core batch processing, which had begun to push later into the overall daily processing timeline (see chart below), encroaching upon a sequence of service-level agreements that ensured trades got to portfolio managers first thing in the morning.
"We were not meeting some of the SLAs when we started the project, as a result of the increased product sales," comments Kevin Yorgensen, VP and CIO, Prudential Annuities.
Marenakos says he considered implementing another version of VPAS as a means of both reducing the processing load and preparing for future products. But cost analysis showed that it would more than double the required investment and significantly increase system maintenance costs, he adds. Ultimately, Marenakos chose an alternative strategy that attacked the capacity issue through three technology areas: hardware, predominantly in the form of solid-state storage; software, through optimization of long-running legacy code for greater efficiency and automation of manual trading processes; and architecture, by taking VPAS out of the data distribution process by employing better ETL (extract, transform, load) and data management processing.
Cutting the Timeline
"We needed to attack the project from both ends of the batch cycle," Marenakos explains. "We needed to move up on our timeline both the core batch completion and the time trades are sent to the portfolio managers."
In order to score quick wins, the implementation strategy adopted for the program was to choose projects that had the combination of the shortest duration and greatest time-saving benefit, Marenakos relates. "This would reduce the daily pressures of finishing the batch process on time in order to meet SLAs and buy some time to work on the more complex projects."
On the hardware front, Prudential gained some time through both speedier servers and storage appliances, according to Yorgensen. "The hardware is solid state, so speed-to-write time is much faster," he says. "When you're analyzing over a million transactions a night, it adds up pretty fast."
Prudential also increased throughput by rearchitecting the configuration of servers to applications into a more specialized paradigm. "For example, we had servers that used to host both the data and application," Marenakos explains. "We've pulled those apart so that now there's a database server and a separate server supporting the application."
As part of the rearchitecting effort, Prudential acquired an ETL tool to ease the task of distributing data to various parties. "The ETL piece comes in when, for example, we're getting to the point in the daily processing cycle when we need to send data to the hedging team or a VIP broker-dealer client," Marenakos elaborates. "Rather than going right at the database integrated with the application, we can have output-optimized files that are tied directly to ETL."
Prudential completed both the core batch processing phase of the initiative and the optimization of legacy code by November 2010, according to Yorgensen. While Prudential declines to share supplier names, Yorgensen says the company's investment in the capacity initiative was over $10 million dollars, over the project's roughly 18-month duration. The initiative required no new software, and the work was predominantly done with internal resources, with some external consulting help, he points out.
The remaining piece of the initiative is the automation of manual trading processes at the far end of the daily cycle, where files are distributed to fund managers. "The rest of the project will be completed this year," reports Yorgensen.
Prudential has enjoyed major benefits from the work done to this point, according to Yorgensen. For example, the core batch cycle has been reduced from six hours to less than two. And despite having recently crossed the threshold of one million transactions daily, Prudential Annuities' improved infrastructure has enabled the company to hit all of its daily processing cycle data distribution SLA's for four straight months. Additionally, "We have been able to renegotiate the SLAs to provide near-real-time actuarial data from 4 a.m. to 2 a.m.," Yorgensen shares.
These gains not only have enabled Prudential to meet present processing demands but also have enabled continued growth, Yorgensen notes. "We've bought ourselves a fair amount of runway so that as our business continues to grow, we don't have to make further multimillion-dollar investments for quite a while," he says.
Prudential also has reinforced its competitive advantage over other annuity providers, insists Marenakos. "We have many competitors who don't have the technical capability to offer a benefit like HD Lifetime Income," he says. "Right now their infrastructure can't support it, and it's not something that you can build overnight."
The increased processing capacity also offers risk mitigation from a business continuity and reputational risk standpoint, Marenakos notes. In the event of a Sept. 11-like event, companies without capacity to spare lack time to react, he explains.
"We like to be in a position where a client can say, 'Hey, I have a Prudential contract, and I'm good,'" Marenakos says. "That's been another part of this initiative -- we've spent a lot of time around business continuity planning and how to manage such a dynamic book of business and still be able to respond to an event such as that."