Rowboat Advisors, Inc.

We  (+ Parametric, AQR Capital Management, Invesco US, and Neuberger Berman, among others) have published our #directindexing paper in the prestigious peer-reviewed Portfolio Management Research Journal of Beta Investment Strategies. I don't like this about our own work (jointly with Stephen Anderson, PhD), but I think it's a very interesting and novel paper. Also, if you read my #nonarmchair #directindexing (this counts as # 57), you may find the following interesting, as it touches upon fundamental aspects of #taxlossharvesting. If so, please read on: Security returns are symmetric* ; if you disagree & can predict the market direction, you are too rich to be reading this! BUT - after-tax, they are not: if a stock is down, I can sell it to offset a gain elsewhere (and postpone or eliminate tax) - but if it’s up, I can just hold on to it. So, asymmetry creates valuable optionality. This is the main reason why tax loss harvesting (TLH) can improve after-tax returns. Now, if I hold an ETF that tracks index X, but e.g. 20% of X’s stocks are at a loss, I don’t have the option to only sell those. However, with direct indexing, I do. This *additional* optionality is why stock-based (a.k.a. direct indexing) TLH outperforms ETF-based TLH, on average. It comes down to dispersion within the index - in other words, stocks won’t all go up (or down) in unison. When doing direct indexing on a vanilla stock index, we don’t have a choice; the market gives us a certain level of dispersion.   But one can manipulate the dispersion to intensify tax loss harvesting and increase after-tax returns. It’s hard to avoid increasing portfolio risk, but our paper shows that the benefit is worthwhile. In a way, this is analogous to long-short strategies, without the operational complexities and additional cost of short positions. Rowboat Advisors, Inc. would like to thank Parametric’s Paul Bouchey for his feedback on our paper, and MSCI Inc. for their permission to use historical data for their large-cap index. Both are also properly credited in the paper. We have purchased reprint rights; the link is in the comments. #wealthmanagement #wealthtech * I know, log-normal, but keeping things simple here.

New client: Double, a #directindexing #fintech firm, will use Rowboat Advisors, Inc. to power their offering. They raised $3.9M and are backed by Y Combinator. They automate index investing with tax loss harvesting, but with richer functionality & more customizability than what I've seen out there. They use sophisticated features of the Rowboat Portfolio Optimizer, e.g.: - Multiple sleeves - Trading off tax efficiency vs. tracking. - Handling legacy positions The founders went to the “MIT of Canada” & CEO JJ Maxwell previously had a successful exit, so keep them on your radar. ABOUT OUR SOFTWARE Since 2016, we have been building software to power the industry shift to custom taxable portfolios: 1. Our Portfolio Optimizer is the core engine of a DI offering. It manages portfolios by considering a client’s: - tax-lot-level holdings - target allocation or index - personal situation (e.g. marginal tax rates) - preferences (ESG, preference for harvesting losses vs. avoiding tracking error, etc.). Built from the ground up for wealth management, not institutions, with a focus on tax sophistication and performance. A 500-stock optimization takes < 0.1 seconds. 2. Our Tax-Aware Backtester helps tune a taxable investing strategy to a specific client, and present estimated results with very realistic handling of tax - down to details such as loss carryovers. Its open architecture allows you to use it with other optimizers as well. ABOUT ROWBOAT ADVISORS - Senior technologists with deep expertise, including building the software for the industry’s first “robo” #directindexing with TLH in 2013, currently managing billions in AUM. - Two papers in prestigious peer-reviewed journals. - Impressive list of clients. Contact us for more. Mark Wai FINTECH Circle Brent Sullivan Randy Bullard Nicola Diodati Alex Kokolis Alex Kokolis Ron Pruitt, CFA Chris Romano, CFA John Hill, CFA Kyle Birmingham, CFA William Trout Greg O'Gara Scott Smith Eric Pistarelli Scott MacKillop Scott Egner Sachin A. Shah Swati Bairathi Andy Watts, CFP® Dave Stone Marshall Smith Amar Ahluwalia Jakob Pizzera Stephanie Guild, CFA Dan Mercurio Kristopher Heck Samuel Lees Roel Vlemmings Chris Volpe

#nonarmchair #directindexing # 69: Sleeves and Tax Lots, Part # 2 This post will discuss improvements to multi-sleeve account trading. The previous post discussed a situation where: * sleeve s1 wants to sell * sleeve s2 does not * s2 holds the ‘best’ tax lots to sell (e.g. lowest tax impact, or simply highest cost basis) One solution is to swap tax lots between s1 and s2 after we calculate orders. Then s1 gets to sell, and s2 gets stuck with the worse tax lots. This is fine if we only care about tax at the account level (makes sense; that’s what matters to the client) instead of the sleeve level (also makes sense; after-tax performance attribution is just an internal calculation). In this approach, the investing decisions of s1 are based on the tax lots that it *thinks* it has. When we later run a step to choose the best lots across the *entire* account (not just the s1 sleeve), s1 could end up selling better tax lots than it thought (i.e. if s2 has lossier ones), which would be a nice surprise. In rarer cases, s1 could also end up with *worse* tax lots, if e.g. a third sleeve s3 also ends up wanting to sell. On average, the end result for s1 will be better than we thought at order calculation time - but it will be a surprise; we won’t know ahead of time. A possibly better approach would be for s1 to consider *all* tax lots held in the account by all sleeves, i.e. not just those it *thinks* it owns. For example, if s1 is running #taxlossharvesting, but s2 is not, then if s1 and s2 ever have to 'duke it out' to see which one gets to sell the 'good' tax lots, s1 will likely win. It’s kind of why I always drive the least desirable car in the family, whereas my wife drives the most comfortable, and my son the coolest one; they can make better use of the desirable features, and it’s bad for me (s2), but good for the family (entire account) overall. This can get complicated though, because all sleeves have to run in a single optimization, which creates other headaches. Plus, it may be overkill in practice. Our next post will discuss yet another approach. [Pic: not the car I get to drive] #wealthtech #wealthmanagement #roboadvisor Rowboat Advisors, Inc. Brent Sullivan Eric Pistarelli John Hill, CFA Kyle Birmingham, CFA William Trout Greg O'Gara JJ Maxwell Randy Bullard Nicola Diodati Davis Janowski Alex Kokolis Peter Kovac Baridhi Malakar, PhD Don Cody David Bedell Scott MacKillop Scott Egner Alex Gildengers, CFA

#rowboateng # 8: Bug avoidance in our 900,000-line codebase, part 2: Extreme type-safety [Technical] This post describes one way we avoid bugs in our huge codebase: we avoid confusing apples with oranges, which is a common source of bugs. Plus, in practice, it’s more like Fuji vs. Gala apples, i.e. it’s not obvious. Say you want to represent a target allocation. Here are some successive improvements. a) Map<AssetClass, Double> A decent start. E.g. cash = 10%, fixed income = 40%, equities = 50%. b) RBMap<AssetClass, Double> A Java Map will at best cause a runtime exception if you modify its contents. At worst, at worst let you do it. Mutable semantics is a huge risk factor for bugs (see #rowboateng 3 to 5). Our RBMap is immutable, and doesn’t even have such API methods. [This isn’t about type-safety, but worth pointing out.] c) RBMap<AssetClass, UnitFraction> Our typesafe wrapper UnitFraction can only be between 0% and 100%. We rarely need values outside that; if we do, we use different classes. d) Partition<AssetClass> The notion of “a bunch of things with weights that sum to 100%” is general. We created Partition, which enforces that all weights are > 0 (not just >= 0), and which sum to 100%. e) AssetClassPartition etc. Partition<T> uses Java generics to allow any key type. So we create further wrappers for the 3 cases of where the keys are asset classes, or ‘assets’ (securities or cash), or just securities. — The above would have prevented a real bug I had to fix at a previous job: * Some code was using a plain map of asset classes to numbers (option (a), that is). * Some other code expected as an input a normalized partition that excluded cash. For example, if a target has cash/bonds/stocks at 20/30/50%, then it expected bonds/stocks = 37.5/62.5%. * However, the code was only filterout out cash - not normalizing. That is, it was passing bonds/stocks = 30/50%, not 37.5/62.5%. Our current Partition class would have avoided that. The developer (could have been me, I don't remember) would have been *forced* to convert to a Partition (there would be a compile-time error), and then realize that the percentages *have* to be normalized to sum to 100%. And we’d realize it at compile time, not at runtime (i.e. much later, and only if / when a special case were to occur). Hat tip to Jeff Holt who first indoctrinated a former C++ guy with this more Java-y idea. [Pic: Extreme Sports, from the Simpsons] #wealthmanagement #wealthtech #roboadvisor #directindexing Brent Sullivan David Bedell Chris Romano, CFA Baridhi Malakar, PhD Peter Kovac John Hill, CFA JJ Maxwell Akshay Joshi

#nonarmchair #directindexing # 68: Sleeves and Tax Lots, Part # 1 This post will discuss certain improvements one can make with multi-sleeve account trading. ‘Sleeves’ are a way to ‘virtualize’ different portions of an account, so you can manage and do performance attribution differently for each portion. The custodian doesn’t know about this division. Say you have two sleeves s1 and s2, and they each have a different target. On any given day, it’s possible that s1 wants to sell what s2 wants to buy. In the simple case where the quantities are the same, the two orders should just net out; there’s no reason to send out an account-level order. It’s in-one-pocket, out-the-other. More generally, there can be more than just 2 sleeves, and the *net* quantities (i.e. summing buy and sell quantities across all sleeves) may be to buy or to sell. The last case is the most interesting. The entire account needs to send out a single sell order. Ideally, we should sell the tax lots that are ‘best’ across all subaccounts. ‘Best’ ideally should mean ‘lowest tax impact’, which takes the short-term / long-term tax rate differential into consideration. It can also simply mean ‘highest cost basis’. Anyway, this isn’t the important point here; it’s “tax lot ownership”. Say subaccount s1 wants to sell, but its tax lots are at a big gain, and s2 has the ‘best’ tax lots to sell, at a smaller gain. If so, then the netted order should sell s2’s tax lots, not s1’s. However, since s2 doesn’t really want to sell, we should also transfer an equivalent quantity from s1 into s2. Since the main reason subaccounts exist is for fine-grained attribution, this seems ‘unfair’ to s2. Now it’s stuck holding ‘bad’ tax lots, and its after-tax performance will suffer. At the same time, it’s clearly better for the client overall. So it’s the lesser of the two evils. One way to avoid this is to measure after-tax performance only at the account level, even as we continue to measure pre-tax performance at the subaccount level. There’s more to this, though; stay tuned for next post. #wealthtech #wealthmanagement #roboadvisor Rowboat Advisors, Inc. Brent Sullivan Eric Pistarelli Kristopher Heck John Hill, CFA Kyle Birmingham, CFA William Trout Randy Bullard Nicola Diodati Alex Kokolis Davis Janowski Peter Kovac Baridhi Malakar, PhD Don Cody David Bedell Scott MacKillop Scott Egner Alex Gildengers, CFA

#rowboateng # 8: Bug avoidance in our 900,000-line codebase, part 1 We hate platitudes, but: it’s good for software to have extensive automated tests. This & later posts will discuss specific strategies we use to make it easier to test software, and - beyond testing - to avoid bugs. We like concrete (the adjective), so we’ll have real-life examples. Automated tests help catch problems: * Now: e.g. before you deploy a new feature * Later: if a future change breaks some old functionality. It’s almost 2025, so I won’t even mention manual testing. Testing is like 30 minutes of cardio, or brushing 3 times a day: everyone agrees in theory, but it may feel like a hassle. Such ‘good-for-you’ activities require motivation. A company doesn’t need to worry as much about this; it can just force its employees to write automated tests. However, convenience also matters. If it’s too hard to write tests, we’ll end up with fewer of them, and/or they will test less functionality, just to rubber-stamp a requirement. For example, if a piece of code can take 5 different paths, one may end up only testing the main one, if the amount of code it takes is huge. Code safety and testing are especially important when dealing with money. It’s not like a broken link on Facebook. If you trade the wrong way for a client, there’s a tangible effect - they may lose money, you may run into compliance and legal issues, etc. But even for things that are more benign and recoverable, it matters. A lot of this business is about entrusting your money to someone competent. Messing up even the tiniest detail, however inconsequential, makes you look less competent. Clients may think “well, if this is buggy, then what else can be buggy?”. At @Rowboat, we use several approaches. * Clear distinction between data (“noun”) classes vs. code (“verb”) classes * “Noun” class, with strong semantics and preconditions. * “Verb” classes use dependency injection, which makes it easier to use mocking. * Small classes, to avoid having too many permutations to test. * Converting storage formats (protobuf, object-relational) to in-memory “noun classes”. Our next posts will go into more depth. #wealthmanagement #wealthtech #roboadvisor #directindexing Brent Sullivan David Bedell Chris Romano, CFA Baridhi Malakar, PhD Peter Kovac John Hill, CFA JJ Maxwell Akshay Joshi [GIF: a cult 1990 Greek bugspray commercial]

Ep. 257 of the #WealthTechTodayPodcast exploring the intricacies of portfolio optimization and tax simulation software with Iraklis Kourtidis, CEO of Rowboat Advisors, Inc. 🔑 Key Highlights: - The crucial differences between portfolio optimizers and rebalancers - How to balance multiple investment goals and constraints - Rowboat Advisors' unique approach to tax simulation - The role (or lack thereof) of AI in wealth management software Whether you're a financial advisor, a fintech enthusiast, or just curious about the technology driving modern wealth management, this episode is packed with insights you won't want to miss. Listen now wherever you get your podcasts - https://wp.me/pdTAz8-5Ct #WealthTechToday #FinTech #WealthManagement #PortfolioOptimization #InvestmentStrategy

We are again finalists in the 2024 "Wealthies". Rowboat Advisors, Inc. is pleased to announce that we have been selected as finalists in the #directindexing Technology Providers category of the WealthManagement.com 2024 Industry Awards, for the second year in a row. There is a secular trend of individual accounts shifting towards custom portfolios. After the ~2022 hype cycle peak, it's clear that this is here to stay. This transition will require changes in assumptions and thinking, vs. the world of institutional portfolios and/or pooled investment funds. Our surprisingly popular #nonarmchair #directindexing series of posts offer some original thinking about this secular shift, while eschewing salesiness, chest-thumping, competitor-denigrating, platitude-spouting, etc. We are pleased to be among the company of the other finalists. Sincere thanks to the judges for looking at our submission and selecting us. Davis Janowski Tim Welsh, CFP Randy Bullard Nicola Diodati Alex Kokolis Jeremy Baskin Alex Hagmeyer Boris Bykhovsky Juan Banet James Corcoran Andrew Chin Manju Boraiah Andy Watts CFP® Will Lucken Jonathan Pincus Michael O'Keeffe Panagiotis ("Takis") Spiliopoulos Stephanie Guild, CFA Lai Zhang, MBA Shen Lu Chris Volpe Don Nilsson Paul Bouchey Kartik Sivaramakrishnan

#nonarmchair #directindexing # 41: Reality vs. appearances, part 2: Cash drag This post subseries discusses cases where what’s objectively good for the portfolio vs. what looks good to an end-client may differ. As cash dividends trickle in, they must be invested. There is a tradeoff: * Investing immediately means very frequent trading - especially with #directindexing portfolios with (usually) many small holdings. That looks bad to the client, or at least annoying (too many trade confirmations, etc.) [For simplicity, assume no fixed ‘ticket’ charges for trades.] * However, waiting too long (e.g. once a month) will cause cash drag. That will also look bad to the client (“why is my cash just sitting there?”) Informally speaking, uninvested cash looks worse to the client than an un-rebalanced portfolio. If e.g. the cash target is 1%, but we’re holding 3%, that will look worse than if some other asset class goes from 1% to 3%. The first reaction is to penalize cash deviations more than deviations in other holdings. This doesn’t work well. It doesn’t capture the fact that a rebalance (i.e. any trading that results in at least one sell order) is viewed by clients as less necessary than an investment. Our solution is to run two portfolio optimizations: 1. Allow selling. This step also handles investing cash. If improvement is big, stop.  2. Otherwise, disallow selling, but use a lower threshold. This looks expensive: two optimizations instead of one. However, we do some trickery by reusing some work (e.g. portfolio restrictions) from (1) back into (2), but with some modifications. John Hill, CFA® Kyle Birmingham, CFA William Trout Greg O'Gara Mark Wai JJ Maxwell Randy Bullard Nicola Diodati Cem Er Alex Kokolis Govinda Quish Bradley Sparks Peter Kovac Baridhi Malakar, Ph.D. David Bedell Scott MacKillop Eric Pistarelli Steve DiGiovine, MBA, CIMA®, CAIA® Nathan Di Lucca Brent Sullivan 💸 Kevin Khang, Ph.D. Alex Gildengers, CFA Stephen Anderson, PhD Scott Egner