Tag Archive: Axys


With my long-standing history as a seasoned and impartial technology consultant catering to the wide-ranging needs of Advent users, it should come as no surprise that companies that have moved away from Advent call me to assist them if they have Advent specific needs after their agreements with Advent have lapsed.  In those specific cases, I suspect my independence from Advent is one of the most appealing features of my service, but many Advent users that have ongoing agreements with Advent also retain me to provide a level of service that Advent seems unwilling or unable to provide.

One of the things I get regular calls about is getting Axys running again.  These calls occur either when firms upgrade their servers or when firms that have moved on to competing Portfolio Management Systems dust off their old Axys files with hopes of tapping into Axys again.  My experience consulting to financial services firms using Advent Software for thirty-plus years facilitates my ability to resolve issues like these easily. 

Many of those calls I get start with the caller telling me, “We reinstalled Axys on the server and it isn’t working.”  And inevitably, this tells me more about the underlying issue than the caller ever could.  You certainly can reinstall Axys, but you probably don’t need to because Axys on the server is just a bunch of files that you access from another PC.  The most important thing to keep Axys working properly aside from the proper installation being done (at some point in the past) is making sure that users have all necessary rights to the shared folders.

This article is focused on explaining what the requirements are to empower you or your firm to resurrect Axys.  As usual, I’ll be providing a level of information in this piece that may be more than you need to solve any immediate problem with the hope that info is useful to you in the future.

Axys Versions

There are two fundamental versions of Axys: the multi-user version and single-user version.  To add a little confusion, the multi-user version is frequently referred to as the network version, but both fundamental versions are regularly installed on networks.  So, the network version is a bit of a misnomer.  Among these two fundamental versions, there is also the version of the software, which is at this point typically version 3.8, 3.8.5, 3.8.6 or 3.8.7.  In addition to these, there are also Monocurrency, Multicurrency and Variable Rate versions, to name a few.  Suffice to say, there are a lot of different versions.

Axys Licensing Model

The concurrent licensing model that Axys implements applies to both single-user and multi-user versions.  In both instances, the number of real Axys users typically exceeds the total licensed users, but having a multi-user version allows more than one user to use Axys simultaneously and adds certain multi-user features, such as user-specific settings and separate blotters, et cetera.

Understanding How Axys is Installed

Initially, the single-user version is simpler to install because the primary program (Axys) and supporting programs (Dataport, Data Exchange, Report Writer, et al.) hypothetically only need to be installed once.  That would be true if there literally was only one user using the software on one PC.  In actuality, the single-user version of Axys and supporting programs get installed multiple times in a network environment. They need to be installed once for every user, albeit to the same destination for each user (e.g., F:\Axys3).

During the Axys install process, certain required files are copied to the user’s PC and/or profile and Axys creates registry keys in HKEY_CURRENT_USER\SOFTWARE\Advent.  The most critical Axys registry keys are stored in HKEY_CURRENT_USER\SOFTWARE\Advent\Axys\3.  Although there are several important Axys files, the firmwide.inf is perhaps the most crucial file.  In a single-user installation, this text file, which can be found in the root folder of Axys (e.g., F:\Axys3), details certain settings in use and where all of the other Axys files can be found.

The multi-user version must also be installed multiple times for users, but the initial Axys install varies.  You install it once to the network/primary destination folder (e.g., F:\Axys3) and then install it again for the rest of the users (e.g., F:\Axys3\users\kevin where a firmwide.inf file will be created).  Similar to the single-user version, the supporting programs such as Dataport, Data Exchange and Report Writer would also need to be installed if the user needs those, or if you are trying to make sure all of the users have access to all of the supporting apps. The same registry keys are used for the multi-user install as the single-user version, but the multi-user (a.k.a. network) version adds an additional critical file: the netwide.inf file.

Netwide.inf versus Firmwide.inf

These two files are closely related.  The netwide.inf file should only be found in the root Axys folder of a network install, but firmwide.inf files exist in both single-user and multi-user environments.  The multi-user version is designed to use the settings in the netwide.inf as the system default and have any settings in the firmwide.inf supersede the settings in the netwide.inf.  As a rule, you should never see a firmwide.inf in the root Axys folder of a network install.  You should also almost never see a netwide.inf file in the root of a single-user Axys installation.


A Recurring Axys Installation Bug

With regard to installing Axys, there is a rather annoying issue that has been going on for several years.  It seems that the Axys install will not recognize certain network locations and/or mapped drives.  The fix requires the following registry settings:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]

“EnableLUA”=dword:00000001

“EnableLinkedConnections”=dword:00000001

Once those settings have been applied, the Axys install program will be able to find the mapped drives.  It seems to me that this is an issue Advent should have addressed a long, long time ago.

Understanding Those Axys Shortcuts and Corresponding Registry Entries

The working folder of the Axys shortcut needs to point to the appropriate folder for the firmwide.inf file.  That means that an Axys shortcut for a single-user version of Axys should have a “Start in” folder like F:\Axys3, whereas the multi-user version would have “Start in” folder like F:\Axys3\users\kevin.  Assuming the same install folder was used, the target for these shortcuts would be the same: F:\Axys3\Axys32.exe.  Likewise, the registry entries associated with Axys should match these settings.  When I am looking at a system, I can usually determine if Axys has been installed properly by looking for consistency between the shortcuts and the following registry entries: ExePath, NetPath and UserPath.

In summary, your Axys install is dependent on a few things: the files themselves, access to the location where they are stored and proper mapping to the location of those files in the registry, firmwide.inf and netwide.inf if applicable.  Hopefully, you can get things back online on your own, but if you need assistance with your Advent installation, reach out to me and I’ll do my best to assist you.


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.

Schwab is no longer providing price file downloads that some Axys users have relied on for decades.

When I set out to write this, I had some trouble deciding on the title.  At first, I considered “Schwab Hamstrings Pricing for Advent Users”, but that’s inflammatory and not entirely accurate, so I couldn’t do that.

I could just as easily have titled this blog “Stubborn Axys Users Refuse to Embrace Benefits of ACD Interface” or “Axys Users Slow to Hire Consultants to Address Schwab Point-to-Point Interface Changes”, but in truth Schwab is discontinuing their support for Axys in the data they provide directly to their customers via the Schwab download, so I had to go with “Schwab Discontinuing Support of Axys Point-to-Point Interface – Again?”  Besides, picking one of those other titles would have made me write a blog with a different message.  In advance, I’d like to clarify that this issue only impacts the Schwab point-to-point interface and has no effect on those that receive their Charles Schwab data from Advent’s ACD interface. 

I need to apologize to those who have read my blog regularly in the past.  First, I am sorry I haven’t posted anything in a while.  Additionally, I must apologize that this blog may not seem particularly newsworthy for some.  You may even be thinking, Didn’t this happen eons ago.  The answer is yes and no.

About twenty years ago, there was some drama about the point-to-point interface that Charles Schwab provided to its customers and Advent, being Advent, may have been perceived as attempting to screw Charles Schwab and its customers to make more money.  Schwab, being Schwab, sued Advent – to paraphrase the judge told Advent, “You can’t do that.”

According to what I can dig up now, the firms quit wasting each other’s time and money nearly seven months after that preliminary injunction, coming to a compromise that allowed Schwab to continue to provide their point-to-point data for a period of time.  In my recollection of the events, it seemed much more drawn out.  Fast forward twenty years, and now everyone that is still relying on this particular set of data directly from Schwab’s download is back to square one.

Back in 2002, the underlying issue was that Advent didn’t want Schwab to continue providing the data without going through ACD and Schwab wanted to continue providing the data to satisfy their existing customers, who had grown dependent on getting that data via the point-to-point interface.  From the perspective of those Axys customers, it is easy to understand their position then and now…  it is pretty much free, and it works.  Why would we want to change that?

Somehow, for more years than I would have thought possible these holdouts that either saw no reason to fix something that wasn’t broken or were too cheap to move to ACD continued to do what they had been doing for decades.  I never thought this would have gone on as long as it did.  Alas, as they say, all good things must come to an end.  That is apparently what is happening now.

Schwab is in the process of stopping production of the files that feed Dataport for this subset of Axys users.  Last month, they stopped producing the price (CSMMDDYY.pri) files; they are also planning to stop producing other key files, such as transactions, sometime in 2023.  The sudden inability to create a price file no doubt caused some difficulties for those still dependent on them.  As a result, a couple firms reached out to me.

After a brief discussion with the first firm, I agreed to automate the creation of the missing price file.  According to my customers, both Advent and Schwab were unwilling to assist them with the issue.  Advent’s not planning to make changes to their interface to take in the new Schwab files, and Schwab’s not planning to help clients transform the files into something that can be ingested directly into Dataport.

It sounded way too easy for someone with my experience, and I thought it would only take a “few” minutes.  Somewhat embarrassingly, I spent a few hours creating the automation necessary to do the translation.  However, in a subsequent implementation for another customer, I was able to have a meet-and-greet call with them and a follow-up call to implement and test the solution in their environment very quickly.  All of it was accomplished in a couple hours, and on the very same day the prospective customer contacted me, leading me to believe that future implementation may be performed in a matter of minutes.

Those dealing with what is currently limited to a pricing issue have a handful of choices, none of which are fun to deal with when you need yesterday’s prices now:

  1. The most obvious choice: consider implementing the Schwab Interface via ACD.  It might be worth it.  I am not kidding.  I have plenty of clients that use ACD.
  2. Use a third-party pricing service like IDC/ICE or Telemet.
  3. Key the prices in manually.  I am not recommending this, but it is certainly an option.
  4. Utilize automation to recreate the missing price file (CSMMDDYY.pri) from the security file (CRSYYYYMMDD.SEC) now provided by Schwab.  This isn’t very difficult, and that is what I have done for those who have asked me to resolve the issue for them.

Addressing the pricing issue alone is a stop-gap solution at best.  The larger issue down the road is translating the transaction files, which will need to be done in 2023.  At my clients’ request, I have agreed to look into doing this for them as well, and I will most likely do it.  With my experience building Axys interfaces and doing the requisite transaction mapping et cetera it probably won’t be that big a deal, but it will certainly be more complicated and time-consuming than the Price File Translator was to create.

As always, if this issue is something your firm needs assistance with, please feel free to contact me directly.


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.

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.

This article is a follow-up to two previous articles: one that addresses the future of Axys and another that helps Axys users figure out whether they are on the right version of Axys for their firm.

Almost two years ago, I speculated on what would begood-bad-uglycome of Axys and whether Advent Software would answer to a growing demand among the Axys user base for major product enhancements after several years of minimal but consistent maintenance updates.

Among other things, my blog detailed an expectation for the same old thing as we have seen in the past – a maintenance release – but I also hoped that we would see a major release.  Since the current version was 3.8.5, it made some sense that version 4.0 might be the next release.

At their conference in 2013, Advent formally announced a major release that would include a user interface (UI) overhaul and the addition of permissions.  Advent also indicated that Axys 14.1 would be released in Q2 of 2014.  This was good news to many Axys clients.  I was off by 10 versions, but happy nonetheless that a major new release was in the works!

While I commend the UI overhaul and see those changes as a necessity given today’s technology standards, permissions have never been that big a deal to me or the clients I work with.  As the go-to technical resource for many firms that use Axys, I found we could almost always work around this issue.  The announcement of a major release no doubt made users hopeful that Axys would get the long-awaited attention it required.

 

Understanding Advent’s new versions…

Advent has embraced a versioning system that makes 14.1 the next release after 3.8.5.  From 2014 forward, there are two scheduled point releases one in Q2 and another in Q4. Advent’s other products also share a similar versioning and release schedule.

 

2014

As April 2014 went by I needed to remind myself that there were three months in Q2, and the release could just as easily come out in June.  Like many users I waited and listened, but heard no great news about 14.1.  As it turned out, 14.1 was a beta with no more than a handful of users outside of Advent partner firms participating in testing.   14.2 was released on a limited basis.  Thanks to the new version numbers, some Axys 3.8.5 users were thinking, “Wow! The latest release is 14; we really have fallen behind.”

Relatively speaking, a very small group of users had begun using Axys v14.x.

2015

Axys 15.1 was also released on a limited basis.  Those Axys users that want to try out the latest Axys version now need to fill out a questionnaire detailing information that helps Advent determine whether the software in its current iteration will work satisfactorily enough for them to allow or discourage testing of the Axys in each particular user’s environment.


Ten Things You Should Know About Axys 15.x

  1. The UI is a ribbon bar similar in style to more recent versions of Office.
  2. Though the software and data still resides locally, Axys 14.x and beyond require an internet connection to authenticate users via Advent Direct.
  3. The file formats are the same as Axys 3.8.5; that is one piece of good news for integrators.
  4. The ancillary products that work with Axys remain the same for now. Report Writer Pro, DTCC, Dataport and Data Exchange. There has been no change to those products yet.
  5. Reports can now be produced from the Axys program rather than the reports program (rep32.exe) alone.
  6. The function of specifying lots when positions are sold off has changed. It is no longer a pop-up.  Now users must specify the close method in a comment line that immediately follows the transaction.
  7. An additional server running SQL CE is recommended for the parallel testing phase.
  8. Scheduled scripts need to be amended to include authentication credentials.
  9. It is not available to Axys users running the single user version, but support for single user installs is planned for v15.2.
  10. Advent recommends running Axys 15.1 in a test environment for at least a quarter.

Axys users should understand the need to do a phased and methodical release.  This need is predicated on how long Axys has been around and how many programs and interfaces connect with it.  As it was designed and marketed to be, Axys is still the hub of operations for many firms.  By and large, Axys users have had the product for several years and many have built and or purchased additional tools that integrate with Axys.

Advent wants users to start using 15.x, but only after they have thoroughly tested all of their processes.  The easiest way to accomplish that, as Advent recommends, may be running Axys 15.x in parallel with Axys 3.x for an entire quarter.  One of the best things Axys has going for it is the fact that it works so reliably.  With that in mind, the last thing Advent would want to do is destabilize the platform and call their clients’ favorite thing about Axys into question.  However, a greater sense of urgency with respect to facilitating Axys 15.x implementations and bringing more substantive enhancements to Axys would be refreshing to see.

In 2013, Advent made an informal and perhaps unspoken promise to continue to make substantial improvements to the Axys platform through announcing their upgrade plans and committing additional resources to make enhancements to Axys.  Though Axys users can clearly see the signs that Advent has made a significant additional technology investment in Axys, the majority of Axys users have not been able to take advantage of those improvements yet.

Future improvements aside, the primary reasons to stay the course with Axys remain the same as they have for quite some time:

  1. it is an established standard
  2. function over form
  3. simple to host and maintain
  4. relatively low-cost versus most emerging alternatives
  5. a platform you can build on

Firms that want to adopt the latest version of Axys in 2015 will need to work to make it happen.  I suspect that the best-case scenario for many firms would be for them to start testing with 15.x in 2015 and eventually go live in 2016 after year end processing has been completed.  Given the competitive nature of today’s portfolio management systems, the slow motion release of major Axys updates could lead to more firms leaving Axys (and possibly Advent) to pursue alternative solutions with enticing features they may be able to take advantage of on a more predictable timetable.



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.