Category: SQL Server


Building Advent APX Data Pipeline Integration with REST API

Filed under: APX, Automation, Axys, Data Conversion, Integration, Portfolio Management Systems, SQL Server — Leave a comment
October 14, 2025

Over the years I have published many blogs.  Almost none of them are as frequently visited as Getting Data In and Out of Advent APX and Axys. That is a good indicator that the topic remains relevant, but a long time has passed since it was published. If you have a recent version of APX today, there is another option that was not available back then – RESTful API.   Though I knew the functionality existed within more recent versions of APX, I hadn’t had the chance to implement it with a client yet.

Abstract illustration of interconnected blue and orange lines resembling data flow or network connections on a dark background.

Last year, an APX user approached me, seeking to utilize Advent Software’s API to create data pipelines between APX and their in-house MS SQL Server Data Warehouse (DW).  The APX user identified this work as a prerequisite for them to fully migrate from Axys to APX.  They wanted to maintain the high-level integration they had created between their DW and Axys in APX.

I was somewhat concerned because I had researched previous APX versions related to the API and knew of some of the issues early adopters had encountered. Given that information, I had some trepidation about obligating myself to a project that required implementing the API. At the time I was not convinced, via first-hand experience, that the API would work reliably for their planned application of it.

I tempered the prospective client’s expectations and proposed a flat-rate job focused on determining the feasibility of doing APX API integration in their environment. Our end goal was to develop a couple of data pipelines between the DW and APX, with the caveat that those deliverables, developed in Python and/or JavaScript, would be proof-of-concept work and not necessarily ready for production use.

Together we successfully completed the project in an APX v21.x environment self-hosted by the client. The majority of the work was done over the course of a couple of months and the deliverables were ready to be moved into production almost immediately afterwards, but there were some challenges along the way.  In most of the instances detailed below, we looped Advent in for assistance, and they did a commendable job helping us resolve the issues promptly.

  • Error 403 – Initially, we were getting an error when attempting to use the API.  We reached out to Advent, and they noted that the most recent Cumulative Hot Fixes (CHF) update wasn’t applied and recommended that we install it.  Applying the CHF update resolved the error, and the API worked as expected.

  • Postman functionality – There were a couple of days where Postman was completely unresponsive.  During that brief period, we had difficulty doing even the most basic API testing.  This issue seemed to resolve itself, but we may also have logged out of Postman and logged back in.

  • Error 500 writing data to APX – During dev the functionality to read APX data was working very well, but we found that attempting to write data to APX generated an Internal Server Error.  I assumed that this meant that the data was not being written to APX.  After looping Advent in for another call, we discovered that although the error was being generated, the data was being successfully written to APX. Advent indicated that they would put a fix request in, but it might not happen because v21.x was sunset. With some reservations, I updated my code to ignore the error 500 when we wrote selective data to APX via the API.

If you do reach out to Advent for assistance, make sure you have Postman installed.  Advent has no desire to review your code.  They will want to test the functionality of the API with you using Postman.

Screenshot of a code editor displaying a Python script for updating data via an API. The interface includes files and folders related to API components, test logs, and a main script for API interaction.
Visual Studio screenshot of Python code sample illustrating API use.

What is Required to Get Started with the API?

Utilizing the API requires some detailed set up and work to get up to speed.  It probably won’t be something that just works without some troubleshooting, and there is a bit of a learning curve.  The following list may not cover everything you need to do to get up and running with the API, but it is a good place to start.  I wish there had been a better resource for me when I started working with APX’s REST API.

Here are some tips that should help those interested in implementing the API:

  1. Make sure you are on the latest CHF for your current version of APX.  If the latest hot fixes have not been installed, you may have problems trying to utilize the API.
  2. Download the Advent Portfolio Exchange REST APIs Postman Collection from the Advent Community website.
  3. Create a Postman account if you don’t already have one, and locally install the Postman software.
  4. Load the collection into your Postman profile and review the documentation completely.
  5. Do a search on the API in the Advent community site and read through some of the threads.  The code samples there were simple, but helpful.
  6. Create the client/credential and verify its existence via SSMS.  The client is persistent, so once you have created it, you shouldn’t have to create it again unless you update APX.  Verify the existence of the client (e.g., cc.postman) in the APX dbo.clients table.  If you have trouble creating the client using your code, try using the PowerShell script to create the client.
  7. The user profile you are using needs to have appropriate rights.  Though we escalated my individual user rights in all the documented required areas, I eventually started using the admin user profile, which worked more reliably in our environment.  I believe Advent recommends using the admin user profile if possible.
  8. Test basic APX API functionality in Postman to make sure it works before attempting to create code via C#, Python, JavaScript, et cetera that leverages the API.

Once you have completed the set up required and can use the API to read and write data to APX, you are ready to build out your solution.  If you have trouble with your implementation, validate specific functionality of the API with Postman.

Calling the API

Almost any use case of the API to write or read data from the APX requires the following steps:

  1. Get IdentityServer base address from APX authentication configuration.
  2. Get token endpoint from IdentityServer configuration.
  3. Get token with client_credentials grant type.
  4. Perform whatever API action you want (multiple calls to the API with the access_token are fine).
  5. End your API Session.  The API utilizes one of your APX seats while the session is active.

Those familiar with API use and Python are likely aware that manipulating data can necessitate working with JSON as well as Python dictionaries.  As an example, in order to read data from APX and write data from the DW into APX that is different from what is already in APX, you may need to:

  1. Query APX for the relevant data via the API, which creates a JSON file.
  2. Query the DW for the relevant data.
  3. Load the JSON data received from APX into a Python dictionary.
  4. Parse and compare the APX data from the Python dictionary with the records from the DW.
  5. Add the records that meet the criteria to the JSON payload.
  6. Send a patch request via the APX API.

The following diagram details this workflow.

Flowchart illustrating the data pipeline between Advent APX and a Data Warehouse using REST API, detailing various processing steps and data storage interactions.

To wrap up the project, I created a PowerPoint presentation summarizing and detailing what we did and how it all works to empower the internal development team to understand, troubleshoot, and replicate my work if they need to in the future. I am always available to support the solutions I create, but I prefer that my customers call me because they want to, not because they need to.

Why would you want to use the API instead of IMEX?

There are pros and cons to using the API. It presents an opportunity to use a single unified methodology to integrate data in your environment but may fall short of that depending on the specific needs of your firm.

The pros of using the API include the fact that is is a more modern approach to extracting and importing data at a granular level. The API can be used to pull data such as holdings, select time period performance, etc. In some use cases, APX users are likely extracting and transforming data that they drop into a DW. Some of those transformations, such as recalculating performance figures, may not be necessary when utilizing the API. The API has the potential to be more secure but given that the default password for admin user in APX frequently doesn’t get changed, it probably isn’t any more secure than IMEX in most self-hosted APX environments.

The cons of using the API are that some data elements may still be in flux. Reading and writing certain data points may not be possible via the API, which could force you to use IMEX or other methods (e.g., Replang, public views, stored procedures, SSRS) in addition to the API. It also may be difficult developers that aren’t Advent APX Subject Matter Experts (SMEs) to bridge this gap. Conversely, it may be difficult for those SMEs that are not developers familiar with the API use to implement it on their own.

Using well-established APX import and export methods like IMEX may still be the most efficient and reliable way to import and extract certain data elements from APX. However, going forward, the growing maturity of Advent’s REST API should force tech-savvy management, users, and integrators to ask “Should we be using the APX API to do this?” as they look to forge a modern data stack that integrates APX data, and meets AI-driven demands for more robust data access.

Kevin Shea Impact 2010

About the Author: Kevin Shea is the Founder and Principal Consultant of Quartare; Quartare provides a wide variety of agile technology solutions to investors and the financial services community at large.

To learn more, please visit Quartare.com, contact Kevin Shea via phone at 617-720-3400 x202 or e-mail at kshea@quartare.com.

Tags: , , , , , ,
Comment

Advent’s Worst Enemy?

Filed under: APX, Automation, Axys, Best Practices, Business Continuity, Portfolio Management Systems, SQL Server — Leave a comment
December 21, 2023

I have said it before, and I’ll say it again: if Advent does well, it follows that someone like me should do well, too.  I profit directly from Advent customers when they hire me, and indirectly when companies that provide services to Advent customers hire me.  That said, there is a certain amount of Advent’s dysfunction that helps my business.  In short, I offer what Advent cannot and/or does not want to provide to their customers, and many of my customers hire me specifically because I do not work for Advent.

 

Steeplechase race in 1912, Celtic Park, N.Y., through water

On the other hand, there is a limit to what is reasonable.  If Advent proverbially lights their hair on fire and jumps off a tall building, that is not good for me or my business. With thirty-five years of experience dealing with Advent, acting as an advocate to clients, I have seen some absurd things and have a high tolerance for some of it, but even I will occasionally find myself flummoxed.  It pains me to say so, since I really want Advent to succeed… at least enough that they aren’t losing business to competitors without good reason.  That is bad for their business and mine.

Advent Options

If you are to believe the natural progression of things as they are presented to the masses, it follows that some Axys customers who are frustrated by its limitations can be better served by Black Diamond or APX.  From what I have seen personally, Advent hasn’t had great success moving Axys customers to Black Diamond.  I have seen a few good Axys clients go Orion and Tamarac, but I have yet to see one of my clients go to Black Diamond successfully. This is not meant as a criticism of Black Diamond – it’s just an observation that my typical clients haven’t found the complete solution they are looking for in Black Diamond.

For those firms where Axys is no longer the answer and Black Diamond cannot meet their expectations, APX may offer a viable upgrade path.  Aside from its cost, APX has always been a relatively easy upgrade choice for Axys users to make because it is an Advent option that supports the legacy of Axys, which includes knowledge of portfolio management and performance fundamentals, transactions, processes, reporting, and scripts.  That means that when those customers move to APX, much of the reporting, infrastructure and established workflows can remain the same.

In short, APX offers everything that Axys does, plus the benefits of an Enterprise/SQL server platform.  The incremental learning required for operations staff to go from Axys to APX is very manageable, and things pretty much work like they did in Axys.

Among APX offerings, I know of at least five possible permutations:

  1. APX Self-Hosted on Premise
  2. APX Self-Hosted in the Cloud by a Third Party
  3. APX Dedicated with AOS
  4. APX Dedicated without AOS
  5. APX Multi-Tenant (hosted by Advent)

I have listed these APX environment options in order of my personal preference, based on specific experience with all of the options and the ease with which one can effectively manage, integrate, automate, and enhance systems. From my perspective, the first two options clearly give you the greatest degree of control and autonomy over your own systems. Choosing one of the other three options puts you in a place where Advent is enforcing various controls over your system – good and bad. Firms that have always had complete control over their systems and want to continue to do so should bristle at the very idea of this.

Advent’s Dedicated Hosting Service for APX Users

One that is used to hosting their own APX system on premise might think that hosting via Advent’s dedicated environment would be nothing but a boon, but reality quickly shatters that dream for savvy, hands-on APX users. Advent’s value add here is clearly AOS, but if that is the case, why would they ever sell someone dedicated hosting without the AOS service?  When they do that, the Dedicated Hosting service provided is arguably no better than what a third-party vendor can deliver.  Oh, wait, that’s not true.  It is potentially worse, because the system will be locked down in such a way that you won’t be able to do the things you would be able to do if your APX hosted environment was provided by a third-party resource that needed to make sure you were satisfied with their service.

This is because, without an AOS resource, some things that a firm would want to do to automate and enhance their systems simply cannot be done because they fall under the responsibility of the AOS silo.  You can call Advent support all you want, but they cannot resolve your problem, because only AOS can do these things.

Want to schedule a process to run at a certain time?  You can’t do that.  Do you want to install a third-party product?  You can’t do that.  Do you want to log into the server directly?  You can’t do that either. All of these things are only possible with the cooperation of an assigned AOS resource.   And even if you have an AOS resource, you still cannot do those things, but instead must ask your AOS resource. 

A fitting analogy for comparing the work required in their locked-down environment to what one might otherwise do in a self-hosted environment could be comparing the 100-yard dash to steeplechase.  As a result, the automation that you may create is more likely to resemble a Rube Goldberg machine than a typical streamlined process due to Advent’s forced assistance and rules regarding what can and cannot be done. 

 

Unfortunately, as you invite a higher degree of involvement from Advent vis-à-vis Advent’s dedicated (a.k.a. “managed”) hosting model, you lose control of the systems you are entrusted to manage and improve unless you had the foresight to have Advent agree upfront to the access rights required or are willing to spend countless hours dickering with Advent about the rights, which may ultimately end in frustration anyway.  This comment is not based on my direct experience with these systems alone, but also what I have heard amongst my peers.

Advent basically has the keys to the kingdom in this scenario, and the users are at the mercy of Advent. It’s almost plausible that they cannot allow you access to certain areas of the system that you usually have, but at the end of the day, when you cannot easily perform work that you were able to do in the past when you self-hosted APX, it feels much more like a ruse intended to ensure that Advent gets not just what clients have agreed to pay them, but any other work you might want to perform in the environment related to automation.

However, the problem is that they cannot necessarily perform the same work of a contractor with specific experience Advent may lack.  From my perspective, Advent’s focus in their Dedicated Hosting seems to be maintaining the status quo, not constantly striving to build a better mousetrap to service your business processes.  That is the directive I am looking for from my clients.

Anyone that can’t envision how Advent could consume their money, time, and resources while providing this service to them may lack experience working with Advent, or the imagination necessary to take their own client experiences with Advent and extrapolate the possibilities once Advent has a greater degree of control over their systems.  The frustration this arrangement creates can be amplified if the firms facing this entanglement are committed to long-term, bajillion-dollar contracts.  These large, multi-year contracts could be part of the reason Advent feels comfortable repeatedly saying the one word my clients never want to hear—no.

Over the years, Tamarac, Orion, Addepar and Ridgeline have all made inroads to capture market share from what was once predominantly Advent’s business to keep or lose, and they will continue to do so until Advent makes improving its rapport with clients a priority.  You may have already guessed, but Advent’s worst enemy and biggest threat to the future of their business may be Advent’s hubris, and winning the WatersTechnology Buy-Side technology award for the Best Portfolio Accounting Provider two years in a row is unlikely to change that.  Even so, if you have deep pockets and are truly ready to hand the reins over to Advent, you may be happy with the results.

 

Kevin Shea Impact 2010

About the Author: Kevin Shea is the Founder and Principal Consultant of Quartare; Quartare provides a wide variety of technology solutions to investment advisors nationwide.

For details, please visit Quartare.com, contact Kevin Shea via phone at 617-720-3400 x202 or e-mail at kshea@quartare.com.

Tags: , , , ,
Comment

Getting Data In and Out of Advent APX and Axys

Filed under: APX, Axys, Data Conversion, open systems, Portfolio Management Systems, SQL Server — Leave a comment
April 25, 2013

iStock_000011255731XSmallWhen Advent first introduced The Professional Portfolio (aka Proport) 25 years ago, one feature that contributed  largely to its long-term success was the ability to get data in and out of the program easily.  Advent software has continued to make this feature a priority throughout every iteration of their original portfolio management product line.

In contrast competing products like Centerpiece, which would eventually be purchased by Schwab and rebranded Portfolio Center, appeared to be a black box.  You could see what was being calculated, but could not see the components of the calculation.

Proport files were stored in an open text format and could be easily read and written as necessary.  Axys v1.x, Advent’s premier Windows product at the time, maintained a similar open file structure.  Axys v2.x was the first version to implement a binary file format.  At the time, some users were concerned that the format change would complicate maintenance of existing customized solutions and inhibit their ability to continue to create solutions that exchanged data with Advent’s portfolio management system.

Firms were slow to embrace Axys v2.x and some never upgraded to it.  Perhaps it was concern over the new file formats.  Instead, most firms eventually upgraded to Axys v3.x. Concerns about the format change were moot since Advent also introduced IMEX, which allowed users to import and export files in CSV, tab, and fixed formats.

Exceptions apply, but the IMEX tool facilitates the ability to move data in and out of Axys with relative ease.  The features of IMEX combined with the ability to import transaction and label data through the trade blotter provide a comprehensive means to get fundemental data in and out of Advent Axys and APX.  Additional methods of importing and exporting data follow:

Axys users may write or read data directly to data files if they have knowledge of the underlying data format.  However, this is not a best practice due to changing file formats between versions.  For example, upgrading from Axys v3.7 to v3.8 requires a file conversion process.  Some of the resulting Axys v3.8 files have a different file format, so any process directly writing or reading these files would need to be updated to take the new file formats into account.

APX users may

  1. query the APX database via Excel (and other software programs).
  2. write SSRS or Crystal reports to extract data.
  3. use many other SQL based tools to export and import selected data.

Axys and APX users can

  1. export reports directly to Excel with the push of a button or create a macro that stores report output in XLS and other file formats.
  2. create custom reports via Report Writer Pro, which can easily be changed to CSV format.
  3. modify existing replang reports to build CSV, other text formats, and various Advent file formats.
  4. use third-party Extract, Transform and Load (ETL) products like xPort.

APX (v1.x to v4.x) maintains the functionality of IMEX, but the ability to generate files in a fixed format has been eliminated.  In addition, you can export data to an Axys v3 format.

Due to these capabilities and a host of other Advent features that facilitate automation and integration, Axys and APX users as well as third-party vendors like ISITC.com have developed many custom solutions utilizing Advent Software’s infrastructure to address day-to-day investment operations workflow and reporting requirements.  The building blocks of these solutions faciliate subsequent projects and allow investment firms to further enhance Advent’s portfolio management systems to meet their evolving needs with less effort and cost.

Here is a sample of some VB code we use to integrate and automate data handling of exported Axys and APX data.  The code can be used in Excel with VBA and User-Defined Functions (UDFs) to pull data from Axys and APX like Bloomberg BLP functions are used in Excel. This function is just one of the routines in our library of code that enable us to seemlessly integrate our solutions with Advent’s infrastructure.  I wrote the original source code for this routine twenty years ago and have updated it as necessary to support later releases of Axys and APX.

Using similar resources, integrators can move quickly from prototype to production when developing solutions for Advent users.  In fact, Advent’s most recent annual report continues to cite customers building their own solutions as one of their largest sources of competition.  For instance, a number of firms have created their own Order Management Systems – not that I’d recommend it.

Advisors abhor inefficiency and are typically willing to make a reasonable investment to reduce it.  Automation not only increases efficiency, but lowers risk by eliminating manual processes that may rely on individuals and their exclusive knowledge of manual or semi-automatic procedures.  Some financial services firms have customized their systems to a degree that makes staying on the Advent platform for twenty plus years possible and the thought of switching to another platform regrettable.

Thanks to the way Advent handles getting data in and out of their systems, users can continue using Axys to meet their ever-changing system requirements and leverage most solutions created for Axys on the APX platform.   Similar and potentially better tech options may exist on other competing platforms, but most of those systems lack the maturity, depth of resources, third-party relationships, and corresponding reliability of Advent’s platform choices.  Knowledge and acceptance of these competing products among advisors, employees, and third-party solution providers won’t match Advent for a long time.

As a result, even though technologically superior portfolio management platforms may emerge, many firms will continue using Advent’s best known portfolio management systems for the foreseeable future.

–

About the Author: Kevin Shea is President of InfoSystems Integrated, Inc. (ISI); ISI provides a wide variety of outsourced IT solutions to investment advisors nationwide.

For details, please visit isitc.com, contact Kevin Shea via phone at 617-720-3400 x202 or e-mail at kshea@isitc.com.

Tags: , , , , , , , ,
Comment

Is your portfolio management system open? How much does that matter in 2011?

Filed under: APX, Axys, Custom Reporting, Data Conversion, open systems, Portfolio Management Systems, SQL Server — 1 Comment
January 23, 2011

I take issue with the implied generalization that some portfolio management systems are “open” just because they utilize SQL server architecture.  With respect to data formats, a product using a SQL format can be considered “open” and a product using a proprietary format is thought of as “closed”, but this gross simplification of the nature of systems can be ill-used by marketers that need you to need something new before it is ready to fulfill its promise.

Don’t get me wrong.  I’m all for open systems, and a system that leverages SQL server architecture is almost always a plus in comparison to the alternatives. However, to determine whether purchasing a new system will effectively satisfy their requirements RIAs need to understand what the differences between the systems they are considering mean to them in the short-term and long-term . Most RIAs don’t understand the issues at a level sufficient to grasp the near-term pros and cons of SQL based systems without experiencing them firsthand.

Last year, I read an article which said advisors are being held hostage by Portfolio Management Software (PMS) companies. The article called Advent ‘s portfolio management systems closed, but after I posted a lengthy comment, the article was revised changing their closed comment to refer to Axys rather than APX.

My original comment on the article follows:

It was a thought provoking article. However, Advent has been around for over 20 years. It is as much of a standard as you are likely to get in this industry. dBCAMS+ and Portfolio Center have been around about the same time, but Advent’s Axys and APX PMSs are the standard by which other systems are measured.

Though I normally act as an advocate for my investment management clients and not Advent, it isn’t fair to call Advent’s PMSs closed especially when you take into account the scripting, macros, import/export tool and the public views offered in APX. The maturity of the product also makes it easier to find people and resources to help you.

The easiest way to get data from one system to another is hire resources that are qualified to do just that by proof of specific experience. It can be difficult to transfer decades of data, but the issue isn’t necessarily one of standards now. It is difficult because there were not any standards in the past.

Converting a client with 20 years of data can potentially mean bringing a mix of data entered manually, downloaded automatically, and random fields into another system that the data doesn’t easily translate to. The process of translating involves field mapping much the same as you would need to move your contacts from one CRM to another, but it is more difficult because of the nature of transactions that can alternatively appear on one line or multiple lines. Intelligent translation tools interpret multiple lines of transactions simultaneously to determine how individual lines should be translated.

Though Advent does not allow you to import transactions directly into portfolio files, you can import the data easily enough. First you need to convert the source files from your old portfolio management system to Advent’s trade blotter format. Once you have done that you can import them to the trade blotter and then post them to your portfolios.

Getting data out of Advent is not difficult for experienced users. You can export transactions, portfolios, groups, securities, composites, performance files and almost any other data you want. Additional data can be generated as needed via reports written in Advent’s report writing language (REPLANG), or Report Writer Pro which allows you to send report data directly to a CSV format. You can also use SQL Server Reporting Services (SSRS), Crystal Reports, or even Excel to access APX data via SQL.

Users thinking of switching to other portfolio management platforms should take a hard look at the existing infrastructure of their current platform and compare it to the new system before making a switch. Infrastructure includes support for investment instruments/multi-currency, people, partnerships, third-party solution providers, interfaces, support-levels, standards and delivery.

Investment advisors need to understand the value of being able to get data in and out of their PMSs. Advisors should always own their data, and never be at the mercy of their PMS, or service provider for access to data that would be required to switch to another vendor.

With regard to the ease with which you can switch from one PMS to another, no matter how accessible, and open the data seems to be – conversion from one system to another still requires standardization and mapping that increases in difficulty based on four primary factors: the number of accounts, the number of investment types, age of portfolios and quality of data.

Perhaps the conversion of data from one PMS to another can be best understood with the analogy of translating a book from one language to another.  Some things translate very easily while other aspects can be extremely difficult to get across.  I have also heard a bit of a buzz about how much easier it will be to switch from one system to another once firms go to the more commonly used SQL platform, but this is a generalization and not a rule.  The complexity of conversions has more to do with common denominators (tables and data structures) between systems than the type of data format they share.   PMS software that shares the same data format does not necessarily share the same data structures and logic.

For now it is debateable whether the benefits of a system that really is open outweigh those of a platform that is more mature, reliable and robust without being “open.”  If you have any doubt of this ask firms that are on the cutting (aka bleeding) edge and find out how well it all works right now.  Firms that have available staffing resources with the expertise to create added efficiencies through the use of a SQL based system may be able to leverage a SQL based platform at a level that justifies the cost.  Lean firms should think hard about the costs before making a commitment.  There are probably significantly less expensive options to add efficiencies on their existing platforms.

In a perfect world, all of your software programs would transparently exchange data as needed in an open architecture.  Today, however, you still have to do some work to make your software programs exchange the data. In order for PMS products to be truly open, an Application Program Interface (API) or similar mechanism would need to exist for every system, facilitating the transport of data.  Hypothetically, PMS products could share a single underlying data format, but that is unlikely to happen.  In the interim, products like xPort pave the way for firms to extract data from their PMS and produce high-end reports without the overhead of a platform change.

Some PMS companies, like Schwab’s Performance Technologies, have made use of Extensible Markup Language (XML) as a vehicle to automate data extraction in a format that is more easily interpreted by developers unfamiliar with their SQL database.  XML provides a measure of portability that other formats like CSV, fixed format and tab delimited do not.  Unfortunately for those without XML experience, dealing with data in an XML format represents yet another technological challenge.

We are now entering an era where open standards and integration between systems in the financial sector should accelerate dramatically.  In the past year, the big three (Fidelity, Schwab and TD Ameritrade) appear to have acknowledged open systems as the latest required initiative (and marketing buzzwords) to ensure the continued success of their institutional arms.  And, in fact, left unchecked open standards may be the biggest threat to the relative monopoly these firms enjoy as the technical visionaries of the RIA marketplace.  On some level, the openness of systems is an eventuality.

The big three are technology leaders.  By proactively augmenting the technology available to their instutional clients these firms make it easier for RIAs to do business and subsequently attract more business themselves.  Each of these firms deserves kudos for their achievements thus far, but there is a clear conflict of interest here.  Another goal of these competing firms is most certainly to provide competitive and proprietary technology with the potential to sway and keep business income in their coffers.  On the topic of open systems RIAs should listen to what the big firms say, but keep a watchful eye on what they actually do.

The truth of the matter is that you should want your systems to be more open, but not so open that there aren’t sufficient controls.    Firms with relatively simple requirements may never want to change their platform, but be assured that, just as it has in the past, the platform will change in the future.  The transaction cost to change it will go down as PMS provider’s incentives to sunset older platforms increase.  The question is whether it makes more sense to make a switch now or later. 

Whether you are on a SQL platform or not,  you still need to have work done to automate/integrate your systems and create high-end client statements.  For example,  going to the latest version of APX 3.0 with support for SSRS will not get your firm the custom reports they need overnight.  There is considerable work involved and the latest platform is still relatively new.  APX 3.0 provides a platform, but solutions still need to be built for that platform.  There will be more choices in coming years, but right now I suspect there are more reporting choices on the Axys platform.

Spending money on improving systems infrastucture is necessary, but the what, where and when is critical.  Your firm’s technology expenditures should be timed with your firm’s best interests for tangible results in mind.  In 2011, your company may be better served by adding a new trade order management system, or beefing up your research resources rather than moving to a PMS platform that utilizes SQL server.  The issues vary from firm to firm, but for most this decision demands a disciplined cost benefit analysis with detailed specifics not generalizations. 

Those that decide not to move to a SQL server platform this year should revisit the decision annually.

About the Author:
Kevin Shea is President of InfoSystems Integrated, Inc. (ISI); ISI provides a wide variety of outsourced IT solutions to investment advisors nationwide. For more information, please visit isitc.com , contact Kevin Shea via phone at 617-720-3400 x202 or e-mail at kshea@isitc.com.

Tags: , , , , ,
Comment