Technology Considerations for New CLO Managers

Launching a CLO platform requires building institutional credibility from day one. For new managers, the choice of technology provider is not just operational—it’s strategic, affecting readiness, investor confidence, and speed to market. Based on our experience with over a dozen new CLO managers that selected LevPro over the past 18 months, the following considerations are critical:

1. Time to Value 

New platforms starting from scratch typically want to issue a CLO within 6–9 months from their founding, but in that time they must simultaneously hire a team, evaluate systems, set up financing, and raise equity. In addition, they must somehow find the time to underwrite hundreds of credits and build a differentiated model portfolio so they can convince investors to come on board—it’s a daunting task to say the least! 

During this frenetic period, new managers have historically operated out of a series of excel spreadsheets and over email, laying a poor foundation that creates a lackluster signal for investors. 

Having a system that can deliver actual operational value from day one does the opposite—it speeds up underwriting and model portfolio building, creates institutional organization and builds trust with investors. Below, we discuss the 3 main components of time to value and some considerations for how you should evaluate various vendor’s offerings with these in mind.  

2. Data Quality and Flexibility 

CLOs live and die by data—loan identifiers, ratings, and secondary pricing feeds. Poor data quality results in fragmented and time-consuming workflows, off-piste trade booking and can compound into trade errors and other costly operational mishaps. 

New issue data is one particularly important process to establish efficiently as a new manager. Subscriptions to a loan-specific news provider are essential, but the data their news contains still must be aggregated. This responsibility usually falls on the trader or junior analyst, and it typically takes at least 30 minutes per day to compile in excel. It’s then shared with the rest of the team where it’s reviewed across the group. Once an investment decision is made, the operations team then has the role of manually creating the asset in the system and tying in identifiers once available. But there’s often delays for new money identifiers or confusion during repricings and refinancings, when simply identifying the correct identifier is a challenge! As a result, trades are booked on incorrect assets or don’t flow to downstream systems appropriately.  

Some Research and OMS vendors have begun tracking and managing new issue data in a way that can be easily incorporated into a manager’s underwriting process and also can serve as a security master. The vendor will manage the new issue process entirely in the backend so that new issue data is accurate and real-time and trades can be booked seamlessly with the appropriate identifier, eliminating the myriad issues with trade booking discussed above. 

Another area worth considering is how the vendor manages customized data sets. Historically, these fields required a coordinated effort from the vendor and client and typically came with a one-time professional services cost. Thankfully, modern data frameworks have resolved this problem so now vendors built on a newer platform should have a flexible, self-service User-Defined-Field process that will allow for customization so your firm can track your internal process exactly how you want to and adapt over time without a major data project holding up your ambitions as a manager.  

Beyond the underwriting and trading processes, having new issue data, security master data and self-serviceable UDFs from the moment you log into a system creates numerous downstream benefits for new managers because they can natively perform: 

• Relative Value analysis with rich data
• Screen-ability of non-owned names
• Investor Ready Model Portfolio building
• Research Commentary Organization

Data Requirements Managers Should Ask of Vendors 

1. Native Security Master– Does the system include a built-in security master with new issue data that allows for seamless trade booking without manual maintenance by your team, or will my ops team have to manage all data and breaks alone?
2. Self-Service Custom Fields– Can you create and manage user-defined fields without vendor intervention oradditionalcost, so your process can adapt as your data needs evolve?

3. Scalability 

Part of the beauty (and pain!) of striking out on your own as a CLO Manager is that you get to make the tough calls about which processes you systematize from day one and which you wait to implement. The VC cliché to “do things that don’t scale” is often sage advice for startups, but it shouldn’t be your default mode as a new CLO Manager. In fact, sometimes the seeds of scalability are sowed as a result of an easy onboarding. So if there are low-friction systems that are highly scalable (and at a reasonable price point), those should be the obvious choice. 

But how can you tell if a system is low friction and scalable?  

Multi-tenant Software as a Service (SaaS) is key. Multi-tenant SaaS means that all clients share the same code base, which can be improved and iterated on much quicker than Single Tenant, where code must be deployed individually, client by client, resulting in a branched architecture that becomes difficult to manage over time. With a multi-tenant architecture, there is never a massive code update, bugs can be identified much quicker, and everyone receives the “latest and greatest” version. 

For new managers using Multi-tenant SaaS, onboarding time is drastically reduced because new client instances can be spun up in minutes with no configuration needed, especially if the system is data rich. 

Over time, multi-tenancy also creates downstream benefits with support, because all client systems have the same underlying structure, so it’s easier for the vendor’s customer success team to provide a speedy response to your question.  

Single-tenant systems often result in customer service issues over time because the vendor is forced to support an ever-growing number of individual client configurations. If support people leave, the vendor might not have anyone who can answer your question. 

Scalability Requirements Managers Should Ask of Vendors 

1. System Architecture– Is the platform truly multi-tenant SaaS, or does it rely on single-tenant instances that fragment versions and slow support?
2. Customer Support Model– What are the vendor’s average customer response times, and do they offer in-system chat for real-time support?
3. Ease of Onboarding– Can you begin using the systemimmediately(via a trial or day-one functionality), or will there be a lengthy configuration period before you are operational?

Implementation Risk 

For new CLO managers, technology onboarding can be the single biggest derailment to timelines. Even if a system is powerful on paper, if it takes months to configure before a team can actually book trades or analyze credits, momentum is lost and credibility with investors suffers. Unlike other startup functions, a CLO manager doesn’t have the luxury of waiting—operational readiness must be established from day one. 

The challenge is compounded by the fact that CLO technology is never a standalone system: it must connect seamlessly to back-office accounting platforms, trading tools, and compliance engines. Historically, this meant drawn-out implementation projects, vendor professional services bills, and long periods of operating partially “offline” in spreadsheets. For a new manager on the clock to price a first deal within a tight window, this risk is unacceptable. 

Modern vendors are beginning to resolve this issue with pre-built integrations, multi-tenant SaaS models, and “live first” approaches where managers can begin trading immediately while integrations are completed in the background. These shifts have dramatically reduced the risk of implementation becoming a bottleneck. 

Implementation Requirements Managers should ask of Vendors 

1. Pre-built Integrations– Ask whether the vendor has existing, tested integrations with back-office systems such as WSO, Sentry, FIS Virtus, or Siepe. If not, expect long build times.
2. Go-Live Track Record– Instead of asking for “average implementation time,” request specific examples of peer managers and the time it took them to go live across different modules (trading, portfolio management, research).
3. Live before Complete– Can you book trades andoperatein the system before all integrations arefinalized? This is a critical differentiator that separates vendors who accelerate your timeline from those who slow it down.
4. System Architecture– Again, confirm whether all clients are on the same release. If not, version fragmentation will inevitably slow down both onboarding and long-term support.