SaaS and Firm58 (Part 3 of 3)
My previous two posts in this series provided a high-level overview of SaaS and explained the differences between SaaS and other common deployment models in the financial services industry. This final post explores how Firm58 differentiates its SaaS platform and why global exchanges, broker dealers and trading firms trust Firm58 to manage billing, deliver daily profitability reporting and strategic insights via detailed post-trade data, and ultimately improve the efficiency and accuracy of their middle and back office functions.
An Industry in Transition
There is plenty of evidence to suggest the SaaS delivery model is on the rise for financial services firms. A 2009 IDC study claimed U.S. firms will spend 45% of their IT budgets on SaaS applications and Wall Street & Technology magazine predicted 2010 is the Year of the Back Office where even the largest Wall Street powerhouses “are turning to hosted software for non-core functions.” This tech spending trend will continue into next year according to a recent report from Ovum predicting a 4.5% rise in tech spending in 2011.
From the early days of Salesforce and its ubiquitous CRM offering to email and other collaboration tools delivered as hosted solutions, more and more firms are embracing the benefits of SaaS. Beyond the economics, SaaS makes a lot of business sense. Firm58’s customers see the competitive value of differentiating their proprietary strategies, their talent, and their approach to customer service rather than focusing limited IT resources on developing and maintaining the ultimate billing, compensation, or P&L system. Those functions are not core to their business, and they can easily be outsourced to trusted providers like Firm58. Our solution is not only economical and easy to deploy, but it continues to get better, so the value to our customers increases over time.
Building a Trusted Platform
For some capital markets firms, the idea of allowing post-trade data to exist outside the company’s walls is often a non-starter. What these firms don’t realize is that many of today’s hosted service providers have undergone third-party audits to ensure their systems are secure and reliably managed. Firm58 completed a SAS 70 audit in 2009 providing verification of these internal controls and financial requirements for our clients. Today, we are proud to claim some of the largest global exchanges and bulge bracket firms as customers.
Firm58 customers own their data and always will. We protect our customer’s critical information with financial-grade security infrastructure both when interacting via a web browser or transmitting data for processing FIX connections or file uploads. All communication between a browser and the platform includes 128-bit SSL encryption, application security requiring strict password and login rules, and permission-based roles within the application configured to our customer’s specific business requirements. All file or FIX-based data transmissions are secured via private VPN connections or secure copies with certificates directed at secured, “jailed” locations. For more detailed information about our security practices, send us an email request.
Managed Multi-Tenant
In my first post, I cited one of reasons the ASP model was not successful was because “the total cost of ownership between the traditional and ASP model is nearly the same.” Essentially, ASP providers were unable to gain the economies of scale to make the costs beneficial to the customer.
SaaS solves this problem by introducing the concept of a multi-tenant application, whereby a single instance of the application runs multiple customers. Multi-tenancy allows the software vendor to reduce expenses through economies of scale and pass on the savings onto the customer.
In an industry characterized by high speed and high volume, coupled with extremely sensitive data, we had to be creative in the way we addressed multi-tenant issues in the design of the Firm58 SaaS platform. Our solution allows all customers to run in a single instance – reaping the core benefits of a SaaS model – but enabling a tunable, isolated, and secure container to ensure customer data is segregated and not co-mingled.
Firm58 has a range of customers from small floor brokers that process a 1,000 trades per day to large exchanges and banks that process millions of trades a day. Through our Managed Multi-Tenant architecture we can adjust the processing resources for each customer, similar to the way cloud service providers dynamically alter processing resources. Customers that have millions of trades per day or complex calculations and analytics can be allocated more processing power to get their work done sooner.
Finally, because our application performs billing and other post-trade functions, if there’s a need to replay a day, any customer has the flexibility to reset to a prior point in time. Our managed multi-tenant architecture achieves scalability without mixing customer data in the same database objects.
Firm58 has developed a scalable, secure SaaS platform that is uniquely suited to address middle- and back-office trade operations. We’re energized to be at the forefront of a transitioning industry as more capital markets firms move toward hosted software to manage their fees, commissions, and payouts.
SaaS for Financial Services (Part 2 of 3)
My last blog about Software as a Service (SaaS) highlighted the benefits of the SaaS model versus the traditional on-premise deployment model. In this post, I will contrast SaaS with other deployment models that are common in the financial services industry, specifically the service bureau and the application service provider (ASP) .
There are several similarities between SaaS, ASP, and service bureaus deployment models. All are centralized deployment models where the hardware is managed by the software vendor in the software vendor’s facilities, rather than on the customer’s premises. In addition, customers pay a monthly subscription fee with minimal upfront fees, rather than a large upfront perpetual license fee with yearly maintenance fees.
Service Bureau
A service bureau deployment is a common deployment model especially for post-trade (clearing) applications. Also known as facilities managed, the service provider not only hosts the application on their hardware in their facilities, but also provides resources to operate the application on behalf of the customer. This model is unique in providing resources to manage and operate the application as if they were employees of the customer. The service provider bundles the hardware and software costs along with the human resources to operate the application into one monthly subscription fee. On the surface, this model appears ideal for companies that want to outsource a solution rather than building and staffing a solution on their own, but there are significant drawbacks.
- Restricted Use “As Is” – In order to offer a cost-effective solution, the service provider restricts application usage and customizations that tailor the software to the customer business process. The customer has to accept the application “as is,” adopting the functionality and terminology of the service provider.
- Limited integration – Service bureau providers limit the integration points to the customer’s business. For example, the application may only accept trades from the service providers trading platform or only from a select few trading platforms. Service providers use to tout this as “straight through processing,” but it’s really intended to force the customer to use the service providers trading platform. Once data is in the application, service providers make it difficult to get data back out, preventing seamless integration to customer’s environment.
- Older Technology – one of the driving reasons for the drawbacks previously mentioned, is that that the underlying technology is often old and rigid. The application was not built from the ground up using leading-edge Internet-centric technologies.
Application Service Provider
An ASP is a business that began in the late 1990s as an alternate way to finance software and to leverage the providers facilities (building, network, power). In this type of deployment, the service provider hosts the application in their facilities on dedicated hardware for each client. If co-location is desired for business continuity, the customer essentially pays for two instances. ASP is similar to the traditional deployment model, except the software runs in the provider’s facilities which are often more fault-tolerant and higher performing than the customer’s facilities. The customer not only purchases a software license for the application, but also must pay for the dedicated hardware and any underlying software licenses such as a database. The service provider bundles these costs into a monthly fee paid over several years. In order to recoup the costs, the service provider often requires a 3 – 5 year contract. The service provider, in addition to hosting the application, also provides backups and upgrades to the operating system.
The customer operates the application as if it were on premise and contracts separately with a consulting firm to deploy and customize the application to their needs. Software vendors that offer their software via an ASP model typically have not designed or optimized their application to work well over the Internet or with high efficiency in order to able to house multiple customers in a single instance. Because of this, the total cost of ownership between the traditional and ASP model is nearly the same. The ASP model simply amortizes the upfront costs over several years, which is why this model is far less common today.
The emergence of SaaS-based solutions for financial services has replaced both service bureaus and ASP solutions for many capital market firms. As technology innovation continues to forge ahead and speed, flexibility and control remain high priorities for customers.
In the 3rd and final installment of the SaaS series, I’ll cover Firm58’s unique offering and address some of the more common topics that customers and prospects ask about including security, performance, co-mingling data, and disaster recovery.

