Conforming requests for streamlined service

Welcome to this installment of our Nuts & Bolts series, designed to help you and your team with tips and techniques to improve productivity and efficiency. In this article, we’ll tackle one of the toughest challenges managed account service teams face—how to handle the various and disparate streams of client requests while still maintaining operational consistency. The method we choose must work with all of our current upstream “clients” (whether we’re a sponsor taking instructions from advisors working for our firm, or a manager communicating with sponsor distributors), and also must be flexible enough to adapt to new channels of communication for future relationships and/or internal lines of business.

What do we expect to get out of conforming incoming requests? Using technology to service client requests is a precondition to running a business efficiently. Conforming to an internal standard will facilitate business process reuse; allow us to develop a consistent set of rules for evaluating requests, and automate the evaluation process online; and create consistent user interfaces for our team members. Consistency of data and presentation will also make it easier for us to document procedures where necessary, and faster for us to train new employees.

Our basic strategy is simple: define common formats for all requests, and make sure all requests conform to the common format as close to the time they’re received as possible. Then, the rest of our operations can be run without reference to how requests were submitted to us. Sounds too good to be true? Well, with a little planning, and some help from existing industry standards, it’s not as hard as one might think.

Client request data and structure

Our first task is to design a generalized data model for our client request types. In our last series on workflow optimization, we concentrated on requests for cash distributions and for harvesting of tax gains and losses. Let’s add to that list terminations, restriction changes, and (the biggest challenge of all) new account openings.

Defining instruction elements

First, we’re going to need to inventory all of the means through which our back office receives client requests for processing. It might be that they all come in from the same place, but it’s more likely we’re supporting multiple channels of communication. If we’re an investment manager, we have several handfuls of distribution partners who each communicate with us somewhat differently. If we’re a mid- to large-size sponsor, we may have two or three internal lines of business that use different systems to transmit client instructions to our back office.

Let’s assume we’re a broker-dealer offering managed accounts through our own financial consultants who use a web-based portal that allows them to enter new account requests directly. The other request types are submitted to us by email. We also have another line of business that services bank trust departments, where all client requests are sent by fax using forms our firm provides.

Start by collecting an example of each request type (new account, contribution, distribution, restriction change, tax harvest, termination, etc.) from each source (the web portal, the emails, and the fax forms). Emails are unstructured, so in that case, you’ll need to collect several examples of each request type to make sure you’ve covered enough cases to be able to generalize. Organize the examples by request type.

Leveraging industry standards

Fortunately, we don’t need to reinvent the wheel in order to create an internal standard for client request data. Instead, we’ll utilize the Money Management Institute MASS Account Origination and Maintenance Standards and map the elements of our example artifacts to the elements in the AOM messages. The AOM message formats have been developed with the participation of dozens of leading investment managers, sponsors, and solution providers, and offer robust support for all of our target request types. An industry draft of the next release of the AOM messages is available for browsing and download from SourceForge. You’ll need to download the AOM versions of our target request types.

You’ll find the next step is easiest if you have an XML editor handy. Pick a request type to start with, and open the corresponding message .xsd file. (For example, the distribution request is represented by the file mass-aom-distribution-base.xsd. Now find your example artifacts of the distribution requests. For each piece of data on each of your examples, find the corresponding message element using your XML editor. (For example, the dollar amount of a cash distribution is the element <DistribVal>. You’ll find the element documentation entries in Release 1.1 helpful in identifying the appropriate mappings.) Create a spreadsheet to record the mappings for each request type and channel for reference later.

Pay particular attention to information about the request itself that appears in your examples. For instance, how is the investment manager and product identified on the request? These “metadata” values will likely appear in all requests, and handling them consistently now will make things a lot easier later. The AOM standards provide a set of elements for common metadata that appears across requests.

These elements and others appear in the <BusinessMsgIdentification> block in all AOM message formats. Other elements that represent optional information related to client requests appear in the <BusinessMsgInformation> block.

By now, you probably see that the MASS AOM standards provide a way to jump-start standardizing your internal handling of client request data. Besides providing a robust dictionary of data elements, the MASS AOM standards also define structure for the data.

Completing the interface

Now that we’ve mapped our various client requests into a common industry data format, we have to address the question of how we’ll physically get this data in the door. There are many options. We might choose to collect XML files on a file system for later processing. We might store incoming XML in a database. In any case, we’ll need to keep in mind that the decision we make now may affect what kind of downstream processing we’ll be able to offer later.

Because we’re interested in responding as soon as possible to new client requests reaching the back office, we’ve decided that our interface for incoming messages in our standard format will be a message queue. This choice aligns well with our use of an XML-based format for the request data. It will also give us great flexibility later when it comes time to connect the stream of incoming requests to systems that will route and process them.

We’ll save a detailed discussion of how downstream processing will work for a later column. But for now, it’s important to give some thought now to other resources we’ll need to ensure consistency and accuracy in transforming incoming requests into our internal standard format. Specifically, earlier on we mapped metadata elements for investment managers, products, client account numbers, and the like. Now, we need to identify the systems in which the master values for those elements are maintained, and how we can access that master data for the purpose of verifying incoming requests. We’ll need that capability for our next step.

Making connections

Now that we’ve created a message queue to accept requests in our standard format, we’ll work on connecting our upstream channels to the queue. For each channel, we’ll create a lightweight gateway written in Java that will transform the request received into our standard format and place it on the queue. For transformation, we’ll rely on the Java Architecture for XML Binding (JAXB) and our AOM message schemas.

Advisor portal

Currently, our firm’s advisor portal allows advisors to enter requests to open new accounts. Our back office staff logs in to the portal to see a list of new accounts that need to be set up for investment. From there, the staff prints the information from the advisor portal, and routes the printout for action.

We want to eliminate the need for staff to print and route new accounts received through the advisor portal. The first step is to link the advisor portal to our new message queue. We’ve discovered that the advisor portal saves request information in an SQL database, so our gateway in this case will be a software “listener” that periodically checks the database for new request records. When new requests are found, the listener will validate the content using the reference data sources we’ve identified. It will transform valid requests into our standard message format using JAXB and the AOM message schemas, and place the message created on our inbound queue.

Fax and email

Unlike the advisor portal, fax and email received from our financial advisors will require a way for the back office team to do some data entry. Fortunately, the number of fields that must be entered is relatively small for requests other than new account openings. We’ll build some simple web forms for data entry of distribution, termination, tax harvest, and restriction change requests based on the AOM schemas. The manager, product and account information on the forms will be validated using our internal reference data, and errors will be caught at the time of entry. Again, we’ll use JAXB to transform entered data into the MASS standard message format.

Putting it together

The diagram below illustrates our new architecture for conforming inbound requests.

(If you’re interested in this approach, and want to save some development time getting up and running, Peridrome’s Capture solution can help. You can find out more here.)

The future

Our hypothetical firm’s bank trust business is growing, and we don’t want to continue accepting faxes from our bank customers as the numbers keep growing. We’re thinking about offering those customers either a special web portal, or perhaps even a web services API so they can integrate with their internal systems. Either way, our message queue interface is a great platform from which to expand. Our downstream processing will already be in place for whatever comes next.

Now that we have defined a standard format for handling client requests, our next column will discuss characteristics of a highly-automated, exception-based environment for servicing those requests. Stay tuned!