Tag Archive: custom


The Impetus to Automate

Filed under: Automation, Axys, Investment Operations, Portfolio Management Systems, Trading — Leave a comment
July 8, 2015

iStock_000000129907XSmallIn my experience working with investors across the nation both small and large, there is at least one recurring theme.  Their sophisticated workflows hinge on semi-automatic processes that rely in part or completely on people.  I suppose that is a good thing when operator oversight is a plus, but when I get involved most of these firms have realized that they literally want to push a button and have things done as simply, quickly and reliably as possible.

Ten years ago, one of my clients experienced organic growth so rapid that it drove their firm from one that managed hundreds of millions to billions in assets in less than two years. While investment managers are known to consistently take pains to build processes that allow their businesses to scale efficiently, explosive growth can strain or disrupt established workflows.

In this case, the effect of the growth was dramatic. It demanded that certain processes be automated. One of the most important processes was related to trading foreign stocks in local currencies.  The influx of trades from new business was overwhelming.  Back-office employees that were already working hard needed to work even longer hours to keep pace with the incoming business.

More specifically, the firm’s back office needed to manually enter both transactions to trade currencies and the associated equity trades. In the multi-currency version of Axys, purchases and sales of foreign stocks in local currency require three transactions: two to exchange the currency and one to buy or sell the security.  As a result, every purchase or sale required two additional transactions related to foreign currency exchange.  They were entering three manual transactions in the trade blotter for every trade they made – even partial fills of an outstanding order required these transactions.  The entries to the trade blotter were tedious, time-consuming, and a potential source of operator error; the firm knew they needed to automate them.

Money concept

Understanding the Required Workflows

As part of their process, the firm waited until they got the executed FX rates from an assortment of brokers before they could enter the corresponding trades and post them in their portfolio accounting system.  This backlog of trades created a slew of manual trade blotter work that ultimately had to be done after hours to make sure the firm was ready to trade the next day.

A homegrown Order Management System (OMS) populated the Axys trade blotters of the traders at the company with open trades. Those blotters were utilized to track open trades and never actually posted.  Once the execution info was reported, our automation needed to create the additional transactions that back-office staff was entering manually. The workflow also required that the trade blotters for individual traders be updated to reflect that the executed trades were no longer part of the open trades. In effect, our automation needed to rewrite the traders’ blotters as well as the trade blotter of the operations employee running the app and post the latter.

Building the Prototype/v1

In a relatively quick timeframe (40 hours), we built a working prototype using Visual Basic that:

  1. loaded the outstanding trades from each trader’s blotter into an Access database
  2. created a process where outstanding trades could be selected and associated with trade execution info to generate the required trade blotter entries
  3. imported executed trades to the trade blotter for review and posting
  4. updated the open positions in the trader’s blotters
  5. produced reports (via Crystal Reports) detailing trades pending and actual execution info

In short, the app pulled pending transactions from their homegrown OMS and allowed users to associate foreign currency execution rates and other specifics of trade execution with specific orders to produce the necessary Axys trade blotter transactions automatically.  Once the execution info was recorded, the user would exit the app, which in turn automatically updated the user’s trade blotter and the traders’ blotters.

Version 2

The next version of the app was under development for over six months and cost nearly 40k, but it met the needs of the firm. The core functionality of v1 with respect to workflow was preserved, but we added many features.  In terms of the initial cost, v2 was expensive, but over a period of nearly ten years it required almost no maintenance. The multi-currency trade automation solved an immediate and urgent need when it was originally developed, and continued to save the firm hours of back office processing work every week for nearly ten years, until it was finally decommissioned in 2015 as a byproduct of the firm’s transition to Moxy and Geneva.

Though the application wasn’t cheap to build or maintain initially, it paid for itself many times over during its tenure as an integral part of the daily workflow at firm that knows the value of automation.

About the Author: Kevin Shea is the Founder and Principal Kevin Shea Impact 2010Consultant 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

Creating the Right Benchmark for Your Portfolios

Filed under: APX, Axys, Best Practices, Custom Reporting, Portfolio Management Systems — Leave a comment
March 3, 2013

Account vs InflationReporting a portfolio’s comparative performance against representative benchmarks over various periods of time has been an widely implemented technique of investment advisors for decades.  Firms do this in a variety of different ways, and some methods are more meaningful than others.

Advisors may show the CPI as a baseline index against the portfolio and other indexes in an effort to illustrate how their investments have performed against inflation and hopefully point out the most basic benefit of investing with their firm versus keeping it under the mattress.

If a firm manages equity they may show the the Dow Jones or the S&P 500 indexes.  If they manage international equities, or have a bond component they will likely show other representative indexes.  They may further isolate performance by asset class and show it with the corresponding indexes to facilitate a client’s ability to draw a direct comparison between the performance of like asset classes and underscore the value they add to the investing process of specific asset classes.

PROBLEMS WITH TOTAL PERFORMANCE BLENDS

Firms typically show total performance too, but many run afoul when trying to show a representative index to match total portfolio performance.  Portfolio management systems like Advent Axys and APX have long supported the ability to create blended indexes, but the actual implementation of the feature falls short of real-world requirements.  In the past, many advisors were content to create a blended index with static weights, but firms soon recognized that these ballpark blends weren’t good enough for their requirements because they didn’t accurately reflect the asset mix of their portfolios over time.

Advent Software initially supported the creation of blended indexes in their portfolio management systems (Proport and Axys) through a report that was engineered to create simple index blends.  This method of creating indexes was somewhat limited because index weights couldn’t be changed over time, but it allowed advisors to manage many indexes centrally through the use of scripts and macros, and it also created separate index (DEX) files.  Having separate files allowed clients to track and show a number of blends if they chose to.

Advent improved the feature to some degree by creating the synthetic index, which allows users to change index weights over time on an individual portfolio basis.  The synthetic index feature works best when used to create ad hoc indexes for selected portfolios, but when users try to scale the feature to be used for a large number of portfolios its usefulness tested.  The ability to change the index weights over time is a plus, but updating the info in an automated fashion is not a feature of the system.

AUTOMATED BLENDING SOLUTIONS

In the early 90s, we started working with advisors to create custom blends with dynamic index weights in order to match the ever changing asset mix of portfolios.  This was done by categorizing assets as fundamental asset types, and assigning those asset types to like indexes.  Once the infrastructure was created we created an extract containing the historic month end asset type weights for all portfolios and used those weights along their corresponding index returns over time to create a true blended index.  The process was automated with a combination of Axys reports, macros, scripts and Visual Basic.

Years ago, we  helped firms address the some of the short-comings of the synthetic index feature by creating a product dedicated to creating blended indexes and managing them.  This allowed users to manage the indexes centrally rather than at the portfolio level.

Last year, we revisited the problem of effectively managing custom index blends for Axys and APX users again.  This time we automated the process of refreshing the index weights stored in each portfolio’s corresponding performance file through a process that updates the synthetic weights by stripping the performance files of their synthetic weight values and rewriting them based on each portfolio’s asset mix and correspondingly assigned indexes.  The process builds monthly synthetic index weights for the inception-to-date period.

This most recent update to our index blending automation tool leverages Advent’s synthetic index capability, and adds the much needed automation that users require to implement the existing synthetic index feature in a way that makes more sense.  Unfortunately, there are still limits to the built-in blending functions of Axys and APX.  For example, synthetic indexes create a blend called simply “Blend”, and users trying to show multiple blends need to create those other blends somewhere else and then generate index files, so that they can be shown alongside synthetic blended indexes.

Thankfully, Advent’s import/export functions, scripting and macros allow savvy users to workaround these limitations as long as they are willing to roll up their sleeves and do a little work or know someone who can help.

–

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

Start Working on Your Next Generation of Client Reports Today

Filed under: APX, Axys, Best Practices, Custom Reporting, Portfolio Management Systems — Leave a comment
July 6, 2011

In an earlier blog I emphasized the importance of mainstream client reporting.  As investment professionals once again turn to the dreaded task of busily cranking out their quarterly reports, it is relevant to share the process we have established to help many of them transition from tired, stale reports to a new generation of client reports. 

In this article, I’ll take you through our process for overhauling client reporting drawing upon specific references to a recent project. Whether you opt to utilize a third-party service provider like us, request Report Writing services from Advent, or produce your next generation client reports internally, you should find the following information useful.  Those that want to implement new reports for Q3 or Q4 of 2011 need to start the process now.

Our Process for Improving Client Reporting

Our fundamental approach addresses the most difficult reporting issues first, identifying any show-stopping problems as early in the process as possible.  We are able to create reports using a number of techniques.  If one way doesn’t work, we can always fall back on another, but our goal is to select the right method from the get-go.

1. Review

In the review stage, advisors need to appraise their current client reporting packages with a critical eye in order to identify what is good and bad about them.  In a nutshell, investors must preserve what is highly valued by clients and remove what is superfluous. The ultimate goal should be to create concise, comprehensive reports that are easily understood, allowing clients to view as little or as much detail as they desire.  Many advisors want to create visually crisp and professional reporting packages.  We understand the importance of this;  however, in the area of client reporting, meaningful content should trump form.

Though we are available and qualified to review client reports and make recommendations for new ones, most firms prefer to do this internally. 

2. Mock-up

A new report always starts with an idea.  Oftentimes, this is shown with a mock-up expressing the look of the desired end product.  In some cases, our customers produce mockups in Excel, but others cut and paste pictures together, or simply sketch them freehand.  Any of these options are fine.  As they say, a picture says a thousand words:  the more detailed the pictures, the less you will have to explain to those writing the reports. 

Most clients have a strong preference as to whether reports appear in landscape or portrait. This aspect of your reports will be more expensive to change as you progress further into the project.  We understand that this decision may have more to do with aesthetic presentation issues, but some report layouts simply require more vertical space or horizontal space than others.  If you are dead-set on a certain orientation, you may need to be more flexible about report content.

Over the years, we have created a wide variety of quarterly reporting packages for clients. Some samples of our work that may help you with your mockup appear on our website under the menu titled “Custom Reports for Axys/APX.”  They fall into three categories:

1 – samples of reports produced by extracting data from Axys/APX and generating reports through traditional report writers like Crystal Reports and SSRS

2 – samples generated directly from Axys/APX through the use of compound report macros

3 – older samples of reports that were generated through a variety of methods

While browsing these above samples, click on any report to view it in larger size.

After viewing all of our online samples and PDF documents, our client produced the following mock-ups for us:

3. Draft

The draft process, as we define it, is one where the reports’ framework is established in the chosen environment.  Roughing out the reports helps determine their feasibility. In the attached example, we started by spending a day onsite, drafting the four account summary-type reports that were requested.   We used a combination of REPLANG, Report Writer Pro, and compound report macros. During this phase of the process, we are not overly concerned about individual details. Instead, we focus on the big picture. Is it possible to create the reports requested? What type of challenges will we face? What tools will be required? What resources, including time, will be required?

There are two possible outcomes to this stage:

  • Validation that the reports can be produced in the selected environment, as well as a better understanding of what they will look like and how much time they will take
  • A recommendation for another methodology, such as SSRS or Crystal Reports, based on the difficulties encountered in attempts to draft the basic report framework

After drafting the four requested summary reports, we were in a better position to estimate the amount of time necessary for development, knew what features would be difficult to implement, and were confident that we could deliver the reports on time.  Our client was also included in the process.  As we drafted each report, we sought their feedback to determine whether things were taking shape as intended.

4. Design

A significant amount of time needs to be spent in the design phase, selecting fonts, styles, colors, chart details, and other elements of presentation related to the reports.   Our client preferred to use the traditional Times New Roman font, but this font choice is one of the reasons most Axys and APX reports look so similar. We selected title bars rather than title boxes to give added flexibility regarding the placement and size of report elements.  Colors are very important. In the past, I have seen clients struggle to pick a palette of colors for charts and graphs. Our client picked vibrant colors that complemented their logo. If you are not already familiar with it, Adobe has a very useful and free resource that you can use to select a color scheme for your reports:

 http://kuler.adobe.com

As a general rule, one should complete design of the master page or default style for all reports before moving on to the next phase.  Report writers and developers are not necessarily graphic designers.  You can save your staff or vendor a lot of grief by having your color schemes selected and logos produced by professional designers.  In particular, your designer should produce images of the proper size, format and quality required.

5. Build & Test

We minimize formatting and style changes by beginning work in this phase only when a client has committed to a design specification.  Ideally, we wouldn’t make any changes to design once we have begun the build phase, but some customers change their minds between the design and build phases.  We also occasionally run into difficulties with pieces of the implementation process or come up with a better way to design something in the process of its implementation.

No matter how a report is created, the formatting of the first in a series of client reports to match the design layout is the most difficult.  However, once the initial report is completed, the rest of the reports come together much faster. The bulk of the time on your project will likely be spent on implementation.  This time depends on the number and complexity of reports you plan to produce, and the resources available.  It will likely take days, if not weeks.

In initial testing, we run reports for a small control group that represents the client’s various types of accounts. We also do a number of report runs for the full group of reports that will be run at quarter end. We find that doing full-scale tests is the best way to identify exceptions and deal with them proactively. As we find issues with individual reports, we apply fixes to address them, and must test again to validate the fixes.

In the example below, our client did a great job illustrating exactly what they wanted and let us focus on producing the report.

Account Summary Mock-up

The final report that we created based on our client’s mock-up shown above follows:

To see other samples of the final reports click here.

It took roughly 30 days to produce the final versions of our customer’s four account summary reports.  The customer was very engaged in the process and highly motivated, facilitating progress by providing quick responses to our questions.   Similar projects take 4-6 weeks, but could take significantly less time if you are working from established reports that just need modification.  You may remember that our initial draft took a day; we spent the rest of the time working on the more difficult aspects of the project.  Our summary reports brought data that needed verification into focus.  Based on exception testing and other issues, we made our final modifications to the reports’ appearance.

The project referenced in this article included new custom reports, quarterly packaging automation, integration of new custom reports, and conversion of legacy packaging to our new report packaging environment.  The project’s total cost was about 20k, nearly double what it would have been with our preexisting custom reports, but the only recurring cost is maintenance.  Many of today’s alternatives feature a sizable implementation cost and significant monthly fees.

Improving your client reporting is one of the most important things you can do to communicate more effectively.  Your next generation of quarterly statements should make it clear to your clients that you are investing in a process that directly benefits them.  If you do it right, you are bound to receive positive feedback from your clients once they have your new reports in hand.

There is no time like the present to start working on your next generation of client reports.

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 or contact Kevin Shea via phone at 617-720-3400 x202 or e-mail at kshea@isitc.com.

Tags: , , , , , , , , , , , , , ,
Comment

Go Beyond the Limits of Traditional Advent Report Writing

Filed under: APX, Axys, Custom Reporting, Portfolio Management Systems — Leave a comment
November 30, 2010

There are plenty of lackluster reporting packages that get sent to investors, but every once in a while, you may see a reporting package that is truly impressive in terms of content and presentation. When you do see something that looks that good, it is only natural to wonder how it was done and at what cost. If the package is exceptional, then chances are somebody spent mucho dinero to make it so.

Back in the 80s when I started using The Professional Portfolio, the pre-Windows version of what is now known as Axys, there were relatively few easy ways to enhance reporting. Like a lot of things back then, we had to do it the hard way. There were then, as now, limits to what could be done within Advent’s infrastructure. When we came up against something that could not be done, or could not without Herculean efforts, we stepped outside of the environment and utilized programming tools to get the job done.

One of the first major projects I worked on was a client billing system that generated management fee summaries for custodians, and invoices for clients; it had many of the same features that have only recently become available to Axys users. That program was written in QuickBasic almost 20 years ago. In order to produce presentation quality invoices, specific HPGL2 (“printer language”) code needed to be written to format text and shade certain areas. The results were first rate but the effort necessary was daunting.

In the 90s, we started using Visual Basic (VB) to create one-page account summaries for our clients. By 1995 we were using VB and Crystal Reports to create reporting systems that were way ahead of their time, but the work behind the scenes was still considerable. Over the years, report writing products have evolved, becoming more robust and making it simpler than ever to produce sophisticated reports. There are two fundamental ways you can produce better reports in-house: within the Axys/APX environment or outside of the Axys/APX environment

Staying within has the potential benefits of keeping initial implementation costs down, facilitating standard Axys automation techniques, and lowering future maintenance costs. Cost may be kept in check by nature of the fact that the Axys/APX system’s rigid infrastructure puts the kibosh on what can be done. This approach is absolutely fine for firms that have simple reporting requirements and are willing to accept the limits imposed by this choice.

Here are some report enhancing tips for those staying within the Axys/APX envelope:

1. Utilize Axys master pages and consistent reporting styles to create continuity across reports.
2. The macro based compound reporting feature need not be used to create reports that look like they were “shrinky-dinked” to fit on the same page. Perseverance, patience and creativity usually payoff when designing compound reports.
3. Axys formatting has a certain look and feel that is dependent on report writing syntax. Most of the time you want Axys formatting, but if you don’t want standard formatting you can work your way around it by showing an Excel worksheet instead of a graph and formatting the Excel sheet with Excel macros.
4. Advent’s Excel data link can be further leveraged by utilizing Excel graph add-ins to give your reports a presentation quality that exceeds standard faire Excel graphs.
5. Battle-tested integrators should know that the limits of Excel integration can be stretched to allow the insertion of related data that may not be in Axys or the APX database.
6. It is sometimes okay to tell REPLANG a white lie about whether the report is really a one page report to get all the reports you want to fit on the page.
7. APX features “public views” which allow technology savvy users to create reports from the APX database. However, the public views are limited and do not give these same users access to all of the data they would like.

Staying within the confines of Axys/APX comes with a cost. The compound reporting feature can be finicky. Some things that should work do not work as expected. The resulting trial and error testing can be frustrating and time-consuming. In some cases, you may eventually find that you cannot do something that you should be able to do, forcing you to figure out an alternative way to reach your goal. These mindbending setbacks can delay or derail a reporting project.

This is a sample of what we have done working within the Axys/APX environment to create custom reports using compound report macros.To see more samples click on these links: portrait #1, portrait #2, landscape #1 and landscape #2.

Stepping outside of the Axys/APX environment by extracting the data and placing it in a database opens up a new world of possibilities, but it should only be done if complex reporting requirements demand it.

The key perceived benefits of this approach can be best described in one word – flexibility. As a direct result of having data accessible in a standard database rather than a proprietary data format, you gain the ability to use report writing tools like Crystal Reports or SQL Server Reporting Services (SSRS) to produce complex reports efficiently, thereby placing your report developers in a more mainstream development environment where solutions to problems encountered are more readily available. This provides a foundation that empowers consultants/staff to act without necessarily requiring a subject matter expert to facilitate progress.

Some guidelines for creating a successful report production environment outside of Axys/APX follow:

1. Extract all the data you need from Axys/APX. You should have a subject matter expert architect and assist with the development of this feature or buy a product that performs the extract for you.
2. Design a well organized data structure.
3. Import data and perform data quality checks up at the earliest point in your report generation process.
4. Create standard report templates similar to Axys master pages and report styles functionality.
5. Take the time to mockup/document the possible permutations of report packages and determine what the process to generate your reports will look like. Seemingly, little details like page numbers, PDF merging, letterhead, disclosures can be a thorn in your side if you do not plan adequately for them in advance.

This is a sample of what we have done by stepping outside of the Axys/APX environment using Crystal Reports to create custom reports.Click on the following link to see more samples: landscape

Beware; this approach is not perfect either. The newfound, godlike ability to make any report cuts both ways. Because you can do almost anything, you will likely spend more time designing reports than you would have. Popular report writing programs have idiosyncrasies, too. As you develop your reports, you will no doubt be disappointed to learn that your chosen solution set has limitations of its own. Report development in this environment typically takes longer, but has more predictable results and corresponding timelines. Using this method also requires that you retain reliable and responsive resources with the ability to maintain and enhance your system as needs change over time.

The labor required to produce reports outside of Axys/APX is a multiple of what it costs to do so within Axys/APX, but the resulting reporting packages should be easily identified as high-end boutique productions, not standard client reporting packages. For companies that consider their reporting systems a top priority and are willing to allocate the necessary resources to produce uniquely engaging reporting packages, going outside the Axys/APX envelope makes sense.

This article was originally published in the Advent Users Group newsletter in 2008.

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