Securities Trade Life Cycle: Front, Middle and Back Office
On today’s walk, we’re going to talk about the securities trade life-cycle– just boring as dirt– from what happens in the front office– a term I’ll explain on the walk– to how, why, and when it flows to the middle office and the back office– more terms I’ll explain in a sec.
I’m thinking about this end to end. So I’ll be talking about every component of the securities trade lifecycle– in the sequence in which a trade is processed.
As you’ll see, each step is critical. And each step has an impact to how the trade is processed in steps further down.
We’ll cover all that and go into how it all ties into what’s called straight-through processing (STP for short)… one of the most impactful ambitions that security processing companies have… and have had for a long time. STP is basically shorthand for “we can process the trade without people involved… getting companies one step closer to being scalable businesses– not needing more people as they get more business.
So… I’ll try to define all the industry-specific jargon (like STP) that I’m about to use. And we’ll cover the order in which everything happens, the risks at each step and the usual mitigating controls. Even the term “mitigating control” is industry jargon. In plain English, a mitigating control is a series of steps (or a procedure) that a person uses to make sure what they’re doing is correct, reproduce-able and evidence-able. It's just a fancy term for wearing a belt and suspenders – so you’re doubly protected against your pants falling off – which when you’re talking about trillions of dollars– is a very expensive wardrobe malfunction.
So we’ll cover the risks in the processing of securities trades and why there are so many controls to mitigate those risks.
Some quick definitions: OVERVIEW OF THE END-TO-END AND WHY DATA QUALITY MATTERS
the securities trade lifecycle is a series of steps that any trade goes thru– from placing an order (buy 10 shares of Apple), to the settlement of that trade– which if you watched my video on custody banking– is when everything about the buying and selling of those 10 shares is done and dusted.
It doesn’t matter if you’re an investment banker buying 10 shares of Apple, or you’re an individual investor (like you or me), or you work at what are called buy-side firms such as an asset manager, a hedge fund, a mutual fund, pension fund, insurance company, etc. The term buy-side just means that you have an investment strategy and the money to execute that strategy by buying and selling stock.
As opposed to a Sell-Side firm… like an investment bank or an advisory firm or any company – that helps create the conditions of a well-functioning market– bringing together buyers and sellers and making it easy for them to buy and sell.
So… what do we call the institutional actor that buys and sells the securities? The front office.
When you hear about some fancy front-office workspace “built for portfolio managers and research staff providing real-time data from internal and external bla blah… its just what they use– the front office…. to buy and sell securities.
–
Once they’re bought or sold, that purchase flows through some kind of system or process that manages risk and calculates profits and losses (we call that the middle office)... and then it flows to the back office… whose goal is to do everything necessary to settle that trade by its due date.
In the world of financial services, the middle office and the back office are also just called Operations or Ops.
That process from the buying or selling of a security to its quick settlement– in a nutshell– is the objective of the trade life cycle.
So… let’s step back and set the table… slowly. Before anyone executes a trade… before anyone buys or sells anything… before anyone manages its risk or settles it in the markets, what do you need in place?
Let’s go tech for a second. You need a reference data platform… most companies call that a security master or a client master… or they call it by some internal system name… like at Merrill, they called it Quartz… at Bank of America, it was PSM, at JP, Barcap and BNY it was SMDB (popular acronym and completely lacking imagination because SMDB is short for Security Master database). It’s like naming your dog Dog.
A SECURITY MASTER holds information about every security (stocks, bonds, etc.) that everyone in the trade lifecycle will be potentially dealing with. Just like a CLIENT MASTER holds information that everyone needs about every client or counterparty that the trade lifecycle will be dealing with. Again, a counterparty is a person or institution on the opposite sides of each trade: buyers and sellers.
The better your information about securities, clients and counterparties– the more accurate and up-to-date that information is– the higher your chance of achieving STP (straight-through processing).
If you have to process a trade where you don't have the counterparty set up in your data masters– or the data about them is stale– it won't necessarily stop you from executing the trade, but it will add a bunch of painful manual steps (time and effort) to processing the trade end-to-end.
So… back to the definition… the front office buys/sells or “executes” the trade… and there’s always someone on the other side of that trade (if you’re buying, there’s a seller, if you’re selling there’s a buyer) — that we call the counterparty.
That trade is recorded in a bunch of systems– yours, the counterparty’s, the markets’-- and that’s when the fun begins because none of those systems are connected. Every aspect of the trade needs to be reconciled.
For instance, the trade is captured in a front-office system– and because system designers are human and stupid– not every piece of data that the lifecycle will need is captured in that system. Usually, a front office platform captures just enough for the traders to do their job and for the back office to start theirs. That’s usually the minimum details associated with the trade.
I’ll mention– a little further down our walk– what those minimum details are– they’re about 7 pieces of information that front-office system always capture– that they always pass to the back-office system. And it’ll become obvious why having high quality static data– or reference data (that stuff in a security master)– is so important when you need to successfully capture and communicate trade details.
So these are generally two separate systems – front and back office. The one in the front is sometimes called an order-management system or OMS… and the one in the back usually has a three-letter-acronym name that only Ops knows. So if a trade has been successfully captured in one, unfortunately, there is still no guarantee that the trade details will be successfully captured in the other.
Why? Because the back office system might be using a different reference data platform– a different security master or client master– or the freshness of the data might be different from platform to platform.
The key thing to understand is that minus some thoughtful design in both the front and back office systems and minus some rigor with data management practices... data mismatches will happen frequently and each one becomes a reconciliation issue– hard, manual work– that no one wants to do. Its pure tedium.
But just to push the ball forward, let’s say that the front office system successfully captured the trade details and passed what they have– successfully– to the back office system… the one used by operational teams.
Well, there’s still a problem with that data… usually. Because front-office systems– as I said– are built– purposely designed– for the front office, not for post-trade activity. So they don’t capture every bit of data during the trade that will be needed post-trade. They capture a subset and assume that the back office systems will fill in the rest.
That’s where we meet our friend “trade enrichment”-- industry jargon for a process every back office is intimately familiar with. A process that uses their reference data to fill in all the data holes in the trade data that was sent from the front office.
Once the trade data is enriched, the next step is trade confirmation… which is getting the other party to confirm that you got the right data or the data right (because remember… their systems and processes are just as incomplete and broken as yours are). They– the counterparty– are going through the exact same process internally at their shop… with their front-office and back-office.
So is it possible to end up with different details? Yes, and at scale. Not onesie-twosies. Millions of mismatches a day across the markets. Serious inefficiency. Every day, across the world, the trade confirmation process is thousands of front-offices--with their respective back-offices– communicating like crazy… with thousands of other front-offices--with their respective back-offices… all just trying to validate that the detail of each individual transaction is the same at their place AND at their counterparty’s.
Lots of comms– emails, phone calls, carrier pigeons… because each system was designed independently of every other system… and everyone keeps their own version of the data that everyone needs. Their own version of the truth.
–
OK, so let's say that we get to the point where all the counterparties agree on the trade details for an individual trade, what comes next?
The issuance of settlement instructions. That’s industry jargon for communications to the markets– to settlement agents like Custodians or Depositories– that they (as the buyer or seller) are ok with the buy or sell… at a specific price. I went into the roles of Custodians and Depositories like the DTCC during my walk about Custody Banking.
Those folks– the ones who do the final inch of the settlements process– well… up until this point in the trade life-cycle, those folks did NOT know anything about the trade at all. They don’t need to know. They just need someone who they know owns 10 shares of apple to tell them that they sold it to someone else for $1… And that someone else to acknowledge that yes, indeed, they bought those 10 shares for $1.
So once the settlement instruction has been issued by each of the counterparties… everyone just keeps checking the status— what’s called the pre-settlement status– of that instruction.
[Refresh, refresh, refresh]
Once that middleman comes back with a thumbs up, both sides will know that that specific trade was matched by the other side… the counterparty. But given all the complexity and poor data quality, there’s also a pretty good chance that it’ll come back with a thumbs down… that it remains unmatched.
There’s a little loop in the process at this point— if it remains unmatched– as both sides go through the motions again of verifying that all their data matches all the counterparty’s data. They call that TRADE INVESTIGATION and spend a ton of time resolving the reason why a trade was unmatched.
Because for a successful settlement to complete, both sides need to have their instructions match perfectly. Then, a settlement can happen.
So the industry spends gazillions of dollars making sure instructions are matched… despite disconnected systems… despite everyone having their own version of reference data– their own version of the truth..
And even if the instruction is matched, the trade can still fail to settle. Because of father time. There’s a ticking clock during all this. And if that tedious process doesn’t happen fast enough (by what’s called the “due date of settlement”), too bad. Both sides of that trade will be pissed. Success means you got it all right before the due date– that you got the thumbs up from your custodian or depository… or the trade has not settled.
Once that “thumbs up” email comes in, that the trade has officially settled, it’s time for the exchange of securities for cash or vice versa.
This is when we go into whatever system houses the client’s portfolio, whatever system holds their cash balances and their security holdings– and reflect the fact that settlement has occurred for that transaction.
Why should we do that? Because until this point in the lifecycle, this trade has had a status of open with the counterparty. That’s financial exposure– RISK!-- with the counterparty when settlement occurs. This step ends that exposure with the counterparty. We update our books-and-records (industry jargon for the official list of who owns what) and verify or reconcile that the counterparty is updating their books-and-records to say the same thing.
Just for belt and suspenders, we’ll want to make sure that the holdings that are reported to us by the markets– the depositories– the custodians– are exactly the same as we have within our internal books-and-records.
Make sense? That’s a high-level end-to-end.
Let’s reel it all back, start at the beginning and get into the details.
–
TRADE EXECUTION
Trade execution. What is a trade? It's a legal agreement to buy or to sell. Like any transaction, the buyer expects to receive the goods after paying for them and the seller expects the payment after transferring the goods to the buyer. The only complexity that securities add is that both sides of that exchange must happen simultaneously. Otherwise, lots of risk for everyone and for the market itself.
And that’s just the simplest of transaction types: to buy and sell. There are other transaction types: there’s lending, there’s borrowing, there’s something called repo securities (repo is short for repurchase agreement– it’s a form of short-term borrowing for government securities). And there are transaction types that help move securities, like bonds, as collateral.
I’ll get into the details of that last one in a sec.
Just want to quickly reiterate the definition of TRADE EXECUTION: it’s the agreement to buy or to sell between two parties– at least two parties– each of whom considers the other the counterparty,
Who can the counterparty be if you are– for instance– JP Morgan? There are usually two types of counterparty: other investment banks (Morgan Stanley, Deutsche, Credit Suisse). and/or institutional clients– think– the true clients of that bank.
Trade execution needs a dance partner. Could be a brokerage firm. Could be a pension fund.
A trade could be between a broker and a proprietary trader. Quick definition: PROPRIETARY TRADING means that a firm that is taking on a securities position or securities trade for its own account… as opposed to for someone else’s.
A trade could be between two proprietary firms.
Anyone can dance with anyone else. You just need a dance floor and some rules.
In fact, back in the old days, traders did it face-to-face and one party would sell, the other party would buy, and the idea of market-making was just some dude holding up the prices at which they are willing to trade. No one misses those days.
There’s electronic versions of that today. Those blinking bid and ask prices that keep changing.
Saving a lot of cardboard signs.
So… other terms to know. An order… which is not an execution… yet. You order a pizza. It’s not a pizza, yet. An order is when a party says what they want to buy or sell. They usually specify 1) a particular quantity of 2) a specific security at 3) a given price. That’s usually, but there are also less specific orders: like “buy 1000 shares of Apple at whatever the market price is.”
Not all orders turn into an executed trade. For instance, if someone places an order for 1000 shares of Apple at half their current price, there's no guarantee that that trade will be executed.
An executed trade needs someone on the other side of that trade that’s amenable to the conditions… like some fool who wants to sell Apple at half price.
That’s where the term TRADE MATCHING comes into the picture. Electronic markets do this really fast and at scale: someone who wants to buy X is matched with someone that wants to sell X on the same terms.
That’s the definition of an ORDER-DRIVEN MARKET: a financial market where all buyers and sellers display the prices at which they want to buy or sell a particular security, and the amounts they want to buy or sell.
The alternative to an order-driven market: a QUOTE-DRIVEN MARKET– an electronic exchange system in which prices are determined from bid and ask quotes made by market makers, dealers, or specialists. In a quote-driven market, which is sometime called a price-driven market, dealers fill orders from their own inventory or by matching them with other orders.
So… order-driven vs quote-driven. Good to know.
And I think I used the words bid and ask. Industry jargon. A "bid" is the highest price someone will pay for something and an "ask" is the lowest price at the other side will sell that same something. The bid price will almost always be lower than the ask price. And some people call the ask price, the “offer” price.. Because you know, we love our jargon.
Another jargonistic term: your “position.” That’s basic math. If you've bought 1 share of Apple, and you buy 5 more, you've got a position of 6 shares of Apple. You’re ready to retire. But wait, you get a tooth ache and you need cash for the dentist, so you sell 5 of your shares. You've back down to a position of 1 Apple share. Get back to work. Or live with cat food.
–
There’s the tiniest bit of math complexity with positions… and I know this is going to sound obvious– but there’s a very good chance that NOT every stock in your holding was executed at the same price. So if you have 10 shares of Apple (and I use small numbers to keep it simple) some of the 10 shares were probably bought at different prices… even if those prices were different by a penny.
Accounting is important because institutions don’t buy 10 shares, they buy 10 million. And there’s zero chance all 10 million were the exact same price. People use average prices to describe their holdings, but every penny needs to be accounted for.
An active trader or trading institution will have executed many, many trades. So, it’s not particularly useful to know what the average price is. Traders– the front office– need to know both the average price (and all the variations) in order to figure out their next move.
And there is no guarantee that a trader will even want to execute a trade if they’re not armed with the price and purchase-price history. Because the trader ultimately works for– and protects the interests of– their firm– which inevitably cares about its P&L– its profit and loss.
Next question: how does trade execution start?
If you listened to my walk about Fund Accounting, you’ll remember how we talked about investors and investment strategies. Those strategies turn into trading decisions– for instance to buy or sell a million shares of Apple. When the time is right (as determined by that strategy), the front office would place an order with a broker, usually an investment bank.
Depending on the current market price of that security– and whether the strategy needs to wait for a specific buy or sell price, the order would be put in by the front office, the trader OR THE SALESPERSON and it would trigger the next step of the trade life-cycle at their investment bank– or whatever institution is receiving the order.
Wait. I just used the term salesperson. Prolly worth mentioning that there are two types of roles in the front office, traders and salespeople. It's the salesperson who interacts with clients– the stereotypical guy you see in movies like the Wolf of Wall Street… on the phone trying to sell someone on buying this or selling that. Salespeople record the detail of the client’s order– just another way to kick off the trade lifecycle.
So whether its a trader in the front office or a salesperson in the front office, someone inputs the details of the trade into their electronic system– their front-office platform..
What they record is: who the client is, what the product is that’s being bought or sold, whether it’s a buy or a sell, and at what price. It is a large enough trade, one that has at least 10,000 shares of stock, or one that’s worth more than $200,000, then it’s called a block trade. That’s jargon for a trade is a large, privately negotiated transaction– arranged away from public markets to lessen the effect on the security's public price.
All a block trade really adds to the trade life-cycle is scale… and complexity. Because when the order is executed, it’ll prolly need to be split into a number of chunks of the security– each of which might have a slightly different price.
So once the salesperson has the details of the order– and this is important– they’re not allowed to do the next step… one part of that is control… the other is that the salesperson doesn’t have p&l responsibility within the front office. So the salesperson will pass the order on to a trader/broker within their firm… They’ll call them or email them or use their firm’s OMS– the order management system– to put in all the order details.
Then it’s the trader/broker’s part. They’re also called agents and principals. And their part is distinct from the salespersons’ 1) because internal controls need to separate those roles to reduce risk to the bank and 2) because there are legal implications around the way that they act on an individual trade basis. So as an agent, the broker tries to find a third-party willing to trade on the terms of the order. A little complexity there because a third party is only needed if the bank has no position in that security or if the terms of the order don’t match what the bank wants to do with the securities that it does hold. In plain English, if you say that you want to buy 10 shares of Apple for $1 and I don’t hold 10 shares, I need to find someone else who does. Or if you say that you want to buy 10 shares of Apple for $1 and I do have 10 shares but I want $2 for each, then I need to find someone who is cool with selling their shares at $1.
The bank is going to make money from that trade– whether they hold Apple shares or not– whether they want to sell them at $1 or not. They’re going to earn a transaction fee– a commission– on the trade… so they’ll do their best to look for a counterparty. That said, completing the order is not guaranteed. The price might not get any takers. The amount you want might not be available. The fancy term for that is liquidity.
Once the order’s trade terms find their dance partner– BAM!– executed trade.
The other way this can happen is that the client– the one who would have been on the phone with the salesperson– they place the order themselves… think online trading…. And the bank’s systems serve as the agent on that trade.
There are also cases where the bank acts as principal… trading for themself… with their money and/or securities. You would do the same if you were the intermediary. If your drunk Uncle Bob wanted to sell his Apple shares for $1 (instead of whatever sky-high number they’re trading for today), you wouldn’t find someone else to rob your Uncle. You’d buy them yourself and wait for him to sober up. If he wanted to buy 1 share of Apple for $1M, no need to look for someone else. You would sell him your share and wonder where the hell he got a million dollars.
Well, banks get a lot of Uncle Bob requests. And instead of saying “Uncle Bob, put down the drink.” They execute his awful wishes with their own assets. No third-party required.
And its not just Uncle Bob requests. A bank might be holding more shares of Apple than their investment strategy advises… so when someone wants to buy from the market, the bank uses their own shares. They sell directly to the client, reduce their position and exercise a little investment discipline.
That whole dynamic that I just described is one of the reasons why banks put internal controls in place, distinguishing clear lines between the role of a salesperson and a trader. The control tries to protect clients from unscrupulous practices that blur that line. Separation of duties keeps it ethically clean or cleaner.
They’re not doing it just because they’re good people. They are. But they also have regulators watching them like hawks. Banks need to be able to prove to market authorities that their clients did right by them.
When a bank says that it is acting as principal, that implies that they had a position themselves and traded it off of their books.
OK, so that’s trading as agents versus trading as principals.
Either way, a trade gets executed successfully when its terms in its order are met.
Once that’s done, the bank let’s all the parties know the details of the execution: counterparty 1 (Uncle Bob) sold a million shares of Apple for $1 to counterparty 2 (you). The counterparties don’t necessarily see who the other side of the trade is. It just looks like the other side’s broker or bank.
We now know the counterparties, the alleged specifics of the trade… and its time for back-office fun.
What happens post- trade execution…? for each involved party? How do we get to settlement in the next 24 hours?
It starts with Trade Capture. TRADE CAPTURE
Trade capture is the formal process of recording the details of an individual trade or execution. This is the baseline information that the back office needs to do their bits… to fulfill their client’s legal commitment to their counterparty.
So the trader records the details of the transaction. The minimum I mentioned at the top of this walk.
First and most important – the trade date (because the ticking clock started the minute the trade was executed). If this data is incorrect, we’re screwed on multiple levels– not just because of the urgency of the ticking clock… of the trade’s settlement needing to happen– but also because a lot of important events are triggered for the owner by the trade date… for instance, dividends and other corporate actions– they’re all based on exactly when you became the owner of the product. So 1) trade date. Captured! Accurately! We need to know the trade day, time, the hour, the minute.. All of it.
Its also important so you don’t piss off your regulators. Why? Because their job is to protect investors. That’s also why all trading conversations are recorded– if there is the client wants to dispute anything about the trade– the regulators can check the recordings.
Next: settlement date– also known as the contractual settlement date or a value date. Easy enough. – It’s that point in the very near future by when everything in this trade’s lifecycle should be done and dusted.
This is all basic arithmetic. On the trade date (which we’ll call T… like the letter T), you know the settlement date (T+1 or T+2 or T+3 where the plus 1,2,3 is basically the number of work days after which the trade needs to settle). Its something called rolling settlements- its the process of settling security trades on successive dates based on the specific date when the original trade was made so that trades executed today will have a settlement date one business day later (T+1).
That was more complex than it needed to be. Just know that the markets set standards about how quickly you must settle every trade… whether its T+1 one day after the trade or T+50… fifty days after the trade.
If every counterparty’s systems used the same reference data– the same security masters and client masters and market reference data– then it wouldn’t need to be T+1. It could be T+1millisecond… but we’re still decades from that.
I like to think about rolling settlement like each trade lights a fuse– a T+1, T+2 or T+3 day fuse (depending on the market). And every business day, the back office needs to figure out quickly– for each trade– whether to cut the red wire or the blue wire.
I actually don’t give much regard to T+2 and T+3 because clients live in the here and now… and they have modern expectations… what I call T+now.
Can you go back to the old days when it was T+10… yes, but you need a counterparty who is also fond of shag carpetting.
If you both do, glod bless, just remember to capture the trade with the agreed-upon settlement date on it.
What else?
We covered trade date and settlement date. The terms– whether you are buying or selling. This isn’t as straight forward as it sounds because you can short a security (sell it when you don’t hold it… and bet that its price will drop… allowing you to profit from the dip). And that’s just the most obvious example. That’s the buy-or-sell piece of the data.
Then there’s quantity. The number of shares that you’re buying or selling.
The security (or symbol for that security) is important. That’s not as straight forward as you’d think either… given that companies trade across multiple markets and potentially different symbols. Plus, there are products like bonds that have hundreds, if not thousands of identical issuer names, coupon rates, maturity dates… with the only distinguishing factor being that one is dollar denominated while the other is Yen. Its all kinds of fun or maddening, depending on what you’re drinking. The key during the trade capture step is to record the exact product– the exactly unique security identifier– that has been bought or sold.
Next, the price. Whether that’s the equity’s unit price (what one share costs) or a bond’s percentage price (because bond prices are expressed in percentages)... the price is a pretty important detail.
So what did I miss of the 7 pieces of minimum data? The trade date (1), the settlement date (2), whether its a buy or sell (3), the quantity (4), the security identifier (5), the price (6)... And obviously, #7: the who… the counterparties. The exact counterparty, including its location. So, for example, if you've executed a trade with JP Morgan, it is not enough to capture it as JPM. Because there are different business and sub-businesses and organization and suborganizations across JP Morgan. Your counterpary could be in NY, London, Tokyo, Geneva, anywhere… and each is a distinct legal entity. Trading with JP is not just trading with JP. There’s a business context that must be captured.
Ok. So those are the 7.
Let’s quickly talk about the intersection of data quality and risk. Every back office process is really about risk mitigation. Every process is about having a belt-and-suspenders approach to getting the data right, getting the details right… not just in your systems but in your counterparty’s… in your custodian’s, in their depository’s. Anything other than stellar data quality, and we’re at risk of losing money– ours, the client’s, the counterparty’s.
The clock is ticking and our goal is to have impeccably accurate data in every affected system across the Street– and ALL of that… before the date of settlement.
Anything could go wrong. And does. Fat fingering in an extra couple zeros without the period. Data sent is not always data received. Duplicate trades. A checker failing to follow the right steps on the maker. Duplicate changes to duplicate trades. Missing data. Competing version of the truth in the same “golden source.” The Ops person that you’re collaborating with on the other side being replaced by another, less-collaborative person or someone who is much more knowledgeable but therefore much busier mid-way through the process.
Add to that: COVID, or seasonal flooding, or other natural disasters that halve your team unexpectedly– the next week Russia invades Ukraine, or some other man-made disaster happens… extreme volatility in the markets that double the amount of trades for a week, that triple your exception queues– the work that’s manually done.
Given the state of data quality across banks, I’m shocked they’re not falling over every other week.
What compensates for that poor data quality? What compensates for the mess they have to deal with at their counterparty’s shops?
World-class collaboration every day. World class monitoring every day. World class problem identification and resolution every day. For millions of trades with thousands of counterparties.
There’s a word for all that. And its not STP.
Its Ops. The people who staff the back office.
If I had a drink I’d toast you.
–
Alright enough praise to the people doing the hard work.
Next in the end-to-end flow after Trade Capture is Trade enrichment… or more accurately Post-Trade enrichment.
So what is it?
TRADE ENRICHMENT
After successfully capturing the trade (that last step) trade enrichment is the process of going from minimum trade dates– the 7 fields we just talked about– to adding ALL essential information that the back office will need to settle the trade.
In data science, it’s called data wrangling, although its a little bit easier here because most of what we’re wrangling sits in our data masters.. Starting with the incomplete data you have– those 7 fields– we systematically add all the data that should be there… which usually rests in the security master, client master, and reference data masters that we touched on at the beginning.
We enrich the 7 with predefined enrichment rules… and we have rules because we’ve done this a million times. The rules identify things such as the cash value of the trade– how much cash we’re going to need to pay for what we bought from the counterparty… or the flip side: the amount of cash we're due from that counterparty. That one– you’d think– is basic math but it can get hairy when you consider that sophisticated clients are trading across multiple currencies… each of which have dynamic exchange rates.
How you navigate a lot of that is… however your client has previously told you to navigate it. Those client-specified rules are in what’s called the SSI– which is short for Standing Settlement Instructions.. SSI… So a client’s SSI might say that whenever they trade in any market where the default currency is NOt the Yen, the post-trade proceeds should land back in their books as Yen. Japanese clients do that a lot. A little joke about the obvious.
So… we need to have crisp, fresh data about how every client prefers to settle… in every reasonable scenario. There are dozens and dozens of different securities markets around the world, and some clients dabble in one… other clients are deeply involved in 50. We don’t need to squeeze rules and preferences out of every client for every market for every conceivable scenario but we do need to have it for their usual trading habits.
We need to know precisely where their trade started, how they want to navigate that terrain and how they prefer to settle that particular kind of transaction.
Client preference rules can be based on the security type, the location of the trading legal entity, the jurisdiction that they’re trading in, their operating model, their operating discipline, anything they think is relevant to their trading needs.
What other kind of information lives in an SSI? Their custodial preferences. Because big Firms realized after the crash of 2008 that they should custody their assets across multiple custodians… to mitigate risk… and to leverage each custodian for its particular strengths.
And we store all these rules because if we didn’t we’d drive our clients crazy asking them after every trade.
Most firms actually capture those client preferences during their client onboarding process– before a single order is placed.
Do those rules ever change? Absolutely. They change whenever the operating discipline of the client changes. The change when they enter new markets or change operating strategies in existing markets. They change when their banks change, when their custodians change, when the rules of a market change,
SSI is the most critical enrichment source for those 7 trade details. Its add to the enrichement impacts everything, not the least of which is how we manage the client’s expectations– their comms preferences with them and with their servicers, their Ops protocols, everything. How are we going to issue instructions to their servicers, their custodian?
SSI is not the only source of enrichment. Think of all the disconnected systems that a company has internally. Think about how old they are and how each one comes with its own system-specific ID. Well, that trade data needs to be enriched with unique keys to many of those systems.
Bad example: your firm has a 30 year old cash platform. In order to know if the client has enough cash to cover their trade, their buy…. the trade data needs to be enriched with a unique ID to that cash system… a hook that allows for something very basic to happen on that legacy cash system.
Now multiply that example by all your crappy, disconnected systems. If you get trade enrichment right, then you might go from minimum viable trade data (the 7) to hundreds of fields – every piece of data you’ll need to get to a successful, timely settlement.
And that enriched data isn’t just for us. Any back and forth we have with counterparties, needs our trade reference number and their trade reference number… because it would be too easy to just have a common trade reference ID.
Get all that right, and you get one step closer to STP – Straight Through Processing– at least on the data that’s heading out your door. Coming back– not so much– because the outside world– every counterparty– is doing the same trade enrichment for themselves.
Next up in the life-cycle: TRADE CONFIRMATION.
Ok. We have enriched OUR trade data to the point where we have all the data and details WE will need. And I emphasize OUR and WE because we still don't know if our counterparty has the exact same details.
Remember: we have our systems. They have theirs. We have our version of the truth. They have theirs. American politics.
But unlike American politics, when either party’s subjective truth doesn’t match the other party’s, people on both sides of the aisle do their best to get to objective truth. It’s refreshing really.
So the whole point of the trade confirmation process is to get everyone to agree on objective truth. Not about gun control or climate change. About the details of the trade.
Trade confirmation is both sides talking it out… emailing it out… to reduce risk on both sides. It’s the living embodiment of shared responsibility… before time runs out. And both sides lose.
Imagine if we applied this process to public policy. We have three days to all agree on all the question words: the what (the security), the when (the trade date), the where (the market), the how much (the price). The only piece trade confirms ignore is the why (because that’s proprietary).
The other thing trade confirmations do is provide clients with that warm, fuzzy sense that everything is going to be fine. A quickly-received confirm is psychological validation that what they did– the trade– isn’t fake news. And professionals are looking at getting it done, accurately, right now, with urgency.
There is some gaming involved. For instance, if you are proactive and issue a trade confirmation to the counterparty, the ball is entirely in their court. Similarly, if you’re on the receiving end of a trade confirmation, it would be wise to do everything you can to make sure its accurate. Because if you fail or worse, if you make a conscious decision not to check it, the risk is now yours.
Because if it has the wrong what, when, where, and how much–, if there's any loss that the counterparty incurs– unfortunately, they would look at you to make them whole.
It's a very risky approach is to say, yes, I've received a trade confirmation but no, I don’t have the time to compare it to my internal details.
Similarly, if you don't issue a confirmation, you risk losing more relationships than just the one with the counterparty. You risk reputational damage. Regulatory scrutiny. Fines. Law suits. Zombies. Bad things.
There are jurisdictions where if you fail to report the details of a trade for trade matching purposes, you could be fined by the regulatory authorities, regardless of whether you've successfully matched the trade or not. The lack of timely participation in the process is just as hazardous as getting the outcomes wrong.
That means you need to know when confirmation should be issued.
Answer: as soon as possible after trade execution.
How do you issue a trade confirmation?
Well, the client will tell you: email, phone call, the SWIFT network if possible… usually email. Confirms used to be on a piece of paper in the old days. Back then, they used to call it a contract because it marked the verbal contract between two traders.
I’m ashamed to say that fax is still a reasonably popular method for sending trade confirms… in 2023. Because… there’s no way to end that sentence. Fax are evil.
Oh, and I mentioned Swift network without explaining it. SWIFT is an acronym. No one knows what it stands for. Maybe the illuminati do. No. Its the Society for Worldwide Interbank Financial Telecommunication. It started as a Belgian cooperative dedicated to the execution of financial transactions and payments between banks worldwide. In plain english, instead of sending faxes or emails from human-to-human, SWIFT lets you send machine-to-machine trade messages and confirms, helping automate a ton of processes… getting everyone a little closer to STP- Straight Thru Processing.
Swift was founded in 1973. I dare you to come up with a good reason to remember that bit of trivia.
The only other thing to note: it’s a subscription service. Predates Netflix by a quarter century. Way better content.
And speaking of content, what information goes into a trade confirmation?
The trade reference number. Because if our counterparty receives this and they find any glaring errors on it, they’ll call us back. When they do, we’ll want to know what they’re talking about (because their call could be about a thousand different trades with us), so when they call, they’ll read off that trade confirmation number we sent them. And we’ll quickly check our books and records, and BAM– we’ll find the transaction in question.
The confirm also includes the minimum 7 we’ve been talking about.
It’ll include the ISIN code– ISIN in an acronym for International Securities Identification Number. Again, no reason for anyone to remember what ISIN is short for.
It might include the name of the depot or nostro. Depot is jargon for where the security needs to be delivered… usually comes as a cash account number. And a nostro refers to an account that a bank holds in a foreign currency in another bank.
It might include the name of the custodian and their associated account numbers.
And the lawyers make you add a bunch of stuff – like the rules or the ruling body under which the trade was executed. Because, you know, everyone reads that.
Actually, most people check the dates, the amounts and prices.
Everything else is there in the event of a dispute with the counterparty.
The funniest part of this whole thing is that once you send the confirm, the other side compares it with their own books and records and if they agree, they intentionally don't let us know that they agree to it. It’s a legal maneuver in case they’re wrong that its right. We have to assume that their silence means agreement. It’s like a failing marriage
There’s also some electronic trade matching which I’m not going to go into because its done mostly with systems, not people.
OK… So I’m back home… and clearly not done. What did I cover? What didn’t I cover?
I covered: basic definitions of the front office, middle office, back-office, Ops… the important of a security master, client master, reference data, data quality… trade execution… the handoff from the the front office to the back office… the 7 minimum trade details… instruction capture… trade enrichment (taking those 7 make adding everything else you’ll need).. trade confirmation.
There’s a ton I didn’t cover: Trade Settlement, Pre-settlement statuses, unmatched instructions, failed settlements, market-by-market differences, partial settlements, your books-and-records (which I briefly defined) but you need to know how to reconcile your books-and-records. Jeez, I suck. Look I can either let you all Google each one of those and get lame disconnected answers or do a second walk.
Or… maybe I can go up to the house, get some hot tea with lots of sugar and finish this today.
PART 2
So… next in the end-to-end trade lifecycle is TRADE SETTLEMENT!
There’s this thing called a settlement instruction– critical part of the process if the trade is to be settled, done-and-dusted… the goal being to move the securities and/or the cash from one counterparty to the other. Simultaneous. If you do everything else right– from the first part of the walk but you fail to issue this instruction, your trade will not be settled.
So trade settlement would fail, securities wouldn’t move, cash wouldn’t move and everyone would suffer some kind of loss: monetary for sure, but also reputational loss, regulatory… hearing loss– because people will be screaming at you.
So it’s important to know the different types of instructions at this stage. I covered SWIFT message types in the second half of the walk on Custody Banking when I was talking about corporate actions.
Now let’s talk about instructions that trigger the move of securities and cash. The big use case for instructions is what happens in the majority of trades: the simultaneous exchange of securities for cash. But… there are also other use cases: when an instruction should only trigger a movement of securities… without a payment… and the flip of that:, a cash-only movement.
The trade settlement step is also when there’s a lot of matching– specifically, the matching of two sets of (hopefully identical) instructions– 95% of which is done electronically with systems (no humans) but because we’re talking about millions of transactions a day, that other 5%... is still a lot of manual matching… the word manual is probably a little bit of an exaggeration… because everyone pulls together their own bag of tools– mostly Excel macros… to help with the matching…. So… not manual (as Ops leaders would have you believe– that’s their fundraising strategy… to call everything manual… The right word is semi-automated. It loses its burning-platform vibe… because “manual” is scary… “Semi-Automated” at least has the word automated in it… but enough about budget politics… we’re talking about settlement instructions and matching… and everyone is interested in getting the trade to a status of matched, so the actual settlement can happen, and the risk between counterparties is mitigated.
It’s an intentionally-trustless system. Trust-but-verify… is the polite way to put it… but those 3 words– trust-but-verify– essentially mean “don’t trust”... so trustless. The seller needs to pass over the securities and at the same time that the buyer passes over the cash. So they rely on process safeguards.
Think about it. How… if you were a bank… would you settle a trade without risk to yourselves? You would require the client to pay first and only after you have the money in your hands, would you– as a bank– issue the instruction for the delivery of the securities. You’ve seen it in movies a million times– it’s usually drugs for cash or guns for cash but there’s always a little dance as the dealers and the buyers try to reduce the risk of being conned.
Think of the Ops teams at both counterparties as the actors on both sides, pointing guns at the other.
Of course, the risk– the movie double-cross– always comes in that split second when the protagonist– in our case a bank– is actually without either the assets or the cash.
As long as you have one of the suitcases, you’re good. But being without either… the climactic gunfight.
So… what’s on a settlement instruction– the ransom note for the other guy’s briefcase?
Fewer details than the emails we’ve been passing back and forth so far in the trade life-cycle.
It would have… the account number where you want the movement to happen… because every firm will have more than one account number. The comments earlier in the walk about JP not being JP.
The instruction would also have your trade reference number– super important for STP– because, without the trade reference number, you can’t update the details
of the trade within your own trade records.
The instruction would need to be explicit about whether you want to deliver or to receive…. you know, the drugs NOT the cash… because they’re securities, and when you talk about delivery or receipt, it’s all about the securities, not the cash. And there’s usually a custodian involved.
What else is on a settlement instruction? The instruction will have an ISIN on it. We talked about the ISIN before. Like almost everything else on the confirm, the ISIN is trying to anchor the reader in common identifers that the process– up until this point– has been tying back to the internal systems of both parties.
It’s like Google Translate… where one language is your system IDs and the other language is your counterparty’s system IDs.
What else? The settlement currency. That’s where SSI– standing settlement instructions– rear their head again.
Key dates– so everyone is on the same page about the ticking clock.
And the account numbers of the counterparties…
And everything should match on both the confirms issued– you and your counterparty.
And– just to be nerdy– if it’s electronic, it needs to be encrypted– to avoid more sophisticated fraud.
It's amazing that people still use faxes for this. Anyone can fake a fax. So encryption reduces risk… and not like $10 here, $10 there…. We’re talking multi-million dollar temptations on those faxes.
OK. Enough preaching.
What’s the deadline on the instructions? That differs from market to market, custodian to custodian, and depository to depository.
If there’s any commonality among the deadlines though it’s that they wait for the close of business… so no one is panicking at noon. It’s always around six… the evening before
the settlement date….
And that might sound straightforward but remember that trades are executed in multiple markets so… 6 pm in NY is not 6 pm in Brussels is not 6 pm in Kuala Lumpur.
Whether you’re skating to T+1 (trade plus one day), T+2, or T+3, that’s all within a complex global ecosystem. Time zones galore.
Oh and learn your SWIFT codes… which I won’t cover here. Memorize them. Not all of them. You don’t need to know the code for Joe’s bank. But if you work in the space, you’ll have your short list of usual suspects… your common counterparties…. Memorizing their codes will be tedious but it’s like muscle memory for servicing securities.
And while I’m preaching (again): understand your risks. Example: what happens when you miss a deadline? What happens when you will fail to pay the seller on time? Not if…. When. Because it will happen. What’s your process for compensating the sellers, the buyers, and whoever is impacted by your failure? Or the failure of your counterparty… which honestly is also your failure. A failed dance takes two.
–
The bad news is that every step has pitfalls. The good news is that none of those pitfalls are new or surprising.
You issue an instruction. It isn’t received. Your org has a playbook for what to do. Commit it to memory.
There’s nothing new under this particular sun in this particular space.
On top of the usual playbooks for common fails– I can’t tell you what those are going to be because every shop’s process is a little different… because every shop’s systems are a little different— anyway… “On top of the usual playbooks for common fails”-- which you’ll have memorized– the one common practive across all institutions is that you’ll want to escalate internally when anything is off, escalate up *your* management chain.
Most shops require a senior to step in and authorize-or-accept the larger risks that each fail entails. So escalate and often… there’s no shame in it… because it’s effective risk management. Escalating… is you doing your job correctly.
You’ll need to partner with those seniors in resolving settlement issues. It’s not just their awareness you need but many times, their written authority. It’s a useful control, given all the moving pieces.
–
Ok… What’s next in the process? Pre-settlement statuses.
We just finished issuing a confirm and the counterparty is cool with the info we put on it. They issue their settlement instruction to the CSD or custodian– CSD stands for Central securities depository), and now it’s time to once again, wear down our refresh button… waiting to hear back… from the custodian or the CSD… what the status is. Are we matched or unmatched?
There are pre-settlement statuses that you’ll need to be familiar with. And while it would completely logical for every institution across the globe to use a consistent set of comms, what you get will depend on who is sending it.
And you can’t settle if your instructions don’t match… so…
Enter custodian banking… my very first walk….
I wish it were as simple as matched or unmatched but the statuses are tied to the different levels of matching.
Three groupings of instruction statuses: 1) Matched… 2) Unmatched… and 3) Alleged.
The ideal is that first group…. you match ALL the details of your instruction and your counterparty Instruction– perfectly match… the cash amount, the cash settlement amount… everything. But in that group of matched you can also have instructions that play within what are called tolerances.
My high school science teacher– Mr. Jones– used to look at my not-so-perfect math answers and say “that’s close enough for government work.” Anyway… tolerances are Mr. Jones-like rules for instructions that don’t match perfectly but match close enough for government work.
Example. If you’re dealing with Euroclear in Brussels– IF YOU WATCHED my first video about Custody banking, you’ll remember that In Europe, the two largest clearing systems are Euroclear and Clearstream. They’re similar to the DTC in the United States (The Depository Trust and Clearing). The point is that Euroclear and Clearstream provide settlement services for securities.
And If you’re dealing with Euroclear, that tolerance for getting to MATCHED status is 25 bucks… US.
So EuroClear’s “close enough for government work: $25 US dollars.” Everything else has to be accurate in the settlement instructions, apart from the cash value, which can be different by up to twenty-five US dollars or the currency equivalent of that amount.
Go to $25 and 1 cent and even if ALL your other non-cash-value info is perfect… status: unmatched.
In that second grouping of unmatched… you have #1 the non-cash data didn’t match… #2 the non-cash data matched but the cash fell outside the tolerance… or #3 there’s a missing instruction from one of the two players... you or your counterparty.
Missing instructions. Happen all the time. Because you have a couple of days– as does your counterparty– and you can’t know if your counterparty’s shop is running smooth, experiencing some problem that you might not be… and how urgently they’re taking the resolution of this specific trade.
You’ve done everything on your end, you’ve issued your set of instructions but your counterparty is either on fire or they fell asleep. No instruction from them.
From the depository’s perspective, they don’t know whether you or your counterparty recognizes that trade or not. So… no match.
If it was YOU that was sleeping and not your counterparty– they issued an instruction and you didn’t… that’s called an alleged status.
Ok… so that’s 2 of the major types of instructions…. Unmatched (which won’t settle 3 days after the trade… matched (which will settle 3 days after the trade)... and the third grouping is Failed.
How do I explain this?
Ok… I’ll put up a chart at this point. Hopefully up here somewhere.
On the x axis– the columns across the top– it’ll list the Instruction Status (Unmatched, Matched, Failed… in Column 1… Column 2 will be the Trade Date… the next 3 columns will be the countdown to the settlement date (3 days from the trade date)... so Trade Date, the day after (T+1), the day after (T+2), and BAM the Settlement Date (T+3). Maybe the final column will be every day after the settlement date. The Beyond.
Ok, hopefully, you’re looking at it now.
Here’s what it means.
If you send your settlement instruction on your trade date… congratulations, you have your “stuff” in order… There’s a very good chance that your counterparty doesn’t. If your instruction is unmatched on your trade date, you’ll get a Status of UNM2… which stands for Unmet with a priority of 2… the only other priority it could have is 1… but there’s no need to give it an urgent priority one on trade date because both parties still have a lot of time… UNM2… Unmet priority 2. If you send your instruction the day after you trade (T+1), and it’s unmatched, same status UNM2… because you still have time to get your house in order. I’m left to right in that Unmatched row. Wait two days after the trade date (T+2) and it starts getting serious: UNM1 Unmatched Priority 1. Sirens should be going off. Still unmatched by the Settlement date: UNM1 Unmatched Priority 1. Sirens should be going off super loud… because someone’s about to lose some money.
Let’s go to the next instruction, the next row. Matched… and I’d throw Settled in that also… if you sent your instruction on Trade Day and match… good on you… but your code is still FUT not SET… Future not Settled… because you can’t settle before the settlement date. The status back on the matched instruction will be FUT, FUT, FUT for T, T+1, and T+2 until– on the settlement date, T+3… it’ll turn to SET… for SETTLED. You can do a little dance.
Then there’s the final row… the FAILED statuses. The good news is that you can’t fail on your trade date, T+1 or T+2. The other good news is that you only get failed statuses IF you and your counterparty matched.
You can FAIL on the settlement date (T+3) and you’ll get one of 4 reason-for-failure codes. CSEC and USEC mean that despite having matched…. either your counterparty or you don’t have the securities you thought you were selling. C-SEC stands for Counterparty Securities… And U-SEC stands for Your Securities (not your Counterparties).
The other 2 FAILs are the same thing but for Cash. The counterparty doesn’t have the cash in their account to cover their purchase. Or you don’t have the cash to buy the counterparty’s securities.
It's super common… but NOT because they’re broke… out of money or out of securities but because they’re prolly doing a million trades and not every trader can know what every other trader is doing at either shop.
So those last two fail trade statuses are OTH (your counterparty cannot pay) and PROV (you cannot pay).
Tsk, tsk, tsk.
So what does that all mean for how you operate in the back office?
Well, respect the priority 1 status. Those are imminent danger. If you don't prioritize them, you will lose cash.
But it's not just the priority 1s that matter. High-value trades require more attention. If you have 2 priority 1 trades for $1 each and there’s a monster $100M priority 2 trade… well, use common sense.
Another dimension of prioritizing your work. Important clients… and problem clients. If they’re unhappy with your service or they’ve demonstrated that their back office is constantly on fire, then up the priority.
There’s also your own front office to consider. They might have some strategic need… or there might be consistently fat-fingered traders…
Your front office is important to factor in because the front and back should always be in synch.
Oh… and what we started the walk with. Data quality. Stale SSI– stale reference data– missing securities within your masters– and someone will lose money. Maintaining that data is as important as hitting all your deadlines. They’re actually intimately connected.
If you’re struggling with matching instructions, there’s a pretty good chance your SSI is out-of-date. Your pain in matching is directly correlated to the quality of information set up and maintained within your firm’s security master, client master, and reference master.
Ok. Did we spend enough time talking about failed settlements? I suppose not.
Worth a quarter mile or so.
Let’s talk about what happens to the trade and cash values and how everything changes when a trade is NOT settled on its value date.
Because a Failed trade is not a canceled trade.
If you’re the buyer or seller, the cost and/or the proceeds remain the same.
That means that both parties, the buyer and the seller are locked-in to the original trade/cash values.
And being illiquid sucks.
You have a contractual commitment that exists between you and the counterparty, and every day that the settlement is delayed, someone will claim that they’re losing money because of it.
And they’re right.
Trade cancellations– by the way– can come into the picture, but only if both parties agree.
Monetary loss is one impact of a failed settlement. If you’re in the business of running a back office… your reputation also suffers. If one of your clients is the counterparty… not if… BECAUSE one of your clients is the counterparty, you’re signaling that you’re on fire… so it's not just about the opportunity cost to them… the cost of not getting the cash/securities asap. It’s not just that there’s a cash interest loss… meaning if you don’t land the cash, you can’t be earning income on it. Think about how much interest is earned on a billion dollars each day.
My point is that it’s not just money. It’s that if you fail to settle enough, your client’s confidence in you diminishes.
Even if you do what every servicer on the Street does and eat the loss of that interest income.
Ant increased exposure to counterparties is risk.
And that’s all securities servicers are in the business of: risk mitigation. If your middle and back office aren’t filled with risk managers, you’ll lose confidence, trust, and ultimately your clients.
Ok… getting off my high horse.
We’ve filed our instructions. We matched. There were (or are) market-by-market subtleties… which I’m not going to get into… other than to say that the best-performing markets are the ones with aggressive, fine-hungry authorities and regulators. Say what you will about them, they know how to effectively threaten pain… at least to people who care about money.
We walked thru the matching process… literally walked thru. And we talked about how every firm has its own unique and broken process and procedure for addressing unmatched instructions.
Here’s the kicker: even with matched instructions, a settlement can still fail.
So having matched instructions does not guarantee anything… other than: the next step.
Which is:
Verifying that you have the securities and/or money that you matched on. So the next step (and we touched on it with the settlement statuses– remember CSEC, USEC, OTH, PROV– codes if they don’t have the securities… or you don’t or they don’t have the cash… or you dont) so the next step… we verify. Or more specifically, your depository or custodian figures that out.
If the answer is yes… securities are there, cash is there… brilliant! The briefcase full of cash is exchanged for the briefcase full of drugs. By the way, in the movies, they always do this step with “open the briefcase… show me the money… ok, now open your briefcase… show me the drugs.”
And if everyone sees the money and drugs… or in our case, when the depository sees the securities and the cash… the final settlement completes.
What can get in the way of final settlement?
At this point, just father time. Remember, the whole process revolved around a ticking clock. Deadlines that are set as soon as the trade is executed…. Deadlines that can’t be missed.
And your custodian knows this… lives by it.
Their systems– old mainframe system from back in the 70s– do the final pieces in what are called overnight batch processing… That’s jargon for: we fail to invest in modernizing our tech.
So everyone comes in the next morning, and the mainframe elves have moved all the securities and the cash. Generated all the reports that no one reads. And some that everyone read– like a failed trades report. And they see which failure occurred and punish the appropriate elves.
Worth noting that if you have a special agreement with your counterparty and all the custodians in the process, you can do intra-day settlement… but behind the scenes, those little custody elves are shaking their fists at the sky… because magic is an overnight thing.
[shake angry fist at camera]
Failed trade reports are used every day. Large teams of Ops folks– at both your place and at your counterparty’s– read them, pick up their phones to call the counterparty– or craft an unending number of emails– to discuss with their counterparty how to match the unmatched.
In some cases, you have to make a change– an amendment– in other cases they do.
Super useful report– that failed trades report– especially when every day is the crisis day of the trades from 2 days ago.
–
Movin’ on!
Once you’re at the point where securities are moving, there’s something known as partial settlement. Let’s say you sell 10 shares of Apple, and you only have 1 share in your account. In some markets, that 1 share will be delivered against a pro-rata amount (the proportionate amount) of cash will be delivered.
In other markets, it's by agreement between you and the counterparty.
So in a situation where you sold 10 Apple shares, and you have only 1 share available on the settlement date, and you are the seller in a market where they haven’t automated partial settlements, then you call the counterparty and ask them whether they will accept partial settlement of 1 share against the pro-rata cash amount (again.. fancy word proportionate amount – pro-rata).
All buyers reserve the right to say no.
This little side-note is important because every institution is doing thousands of buys and sells… thousands of security movements and cash movements… so partial settlements aren’t particularly satisfying… because the rest of the settlement is still in the ether… but partials are useful because that 1 Apple share you get in the partial might help fill another whole in another end-to-end flow.
That’s a better outcome than unmatched or just flat failed.
And just to be clear, a partial settlement doesn’t negate the original contract. The trade remains intact. It just plays with the timing… giving multiple deliveries and payments, versus the usual (and clean) one delivery, one payment.
The original trade remains intact, it’s not being split in any way. It's just the settlement, the logistics… of the trade.
What can be done to enforce settlement if you’re in desperate, immediate need of ALL the securities you bought?
It doesn’t happen often but you could be an ass and insist on a process called buy-in. Depends on the market and its buying rules and procedures.
You basically issue some comms to the counterparty saying I'm giving you N number of days to deliver and if you fail to deliver by that day, we’ll go nuclear– invoke the buy-in procedure.
You give them a chance, a threat… a warning… whatever lets you sleep at night… and if they deliver in that time frame, yay, you’re set. No harm… the settlement occurred.
If they don't deliver to you though, then it's time to escalate to the market maker… to enforce the procedure. The market maker becomes the buying agent and they step in to play the role of the evicting sheriff. They enforce the settlement through the buying process. The market maker buys the securities from another party and they forward it to you– the landlord.
If the market maker has any additional costs, they charge the seller, the party that failed to deliver.
Depending on the market, this might be common (because force is needed)… or rare because everyone lives in a glass house.
–
Ok… take a breath… so we’ve been talking about the settlement process but I don’t remember if we defined it.
It should be obvious by now though.
Settlement is the transfer of securities and cash between buyer and seller.
The next step is reflecting that settlement– in other words.. Writing its details into your official books and records. Remember the definition of books and records: their your official ledger of who owns what and how much.
Up until the settlement, your books and records haven’t cared about the trade… because it wasn’t real.
But once the settlement has occurred, it’s real. It’s fact. It needs to be on your books.
This step– what's also called the clean-up– also eliminates the exposure– the risk– associated with the no-longer-open trade. It’s an important step because it aligns your static books and records with the dynamism in the real world– the trading world.
Every settled trade needs to be reflected in your books and records.
And this is where we start talking about reconciliation, which thankfully, is our final piece of the end-to-end securities trade life cycle.
How do you reconcile?
Carefully.
You assembly all the evidence… in a kind of audit trail… the instruction reference ID, your unique trade reference number, and everything you sent and received (to the counterparty, to the custodian, to the depository). Everything. And you meticulously check and re-check… not just your answer… but how you got to it.
Show your work.
Super important because recon is the control of all controls.
It needs to be performed thoughtfully and urgently– making it doubly hard. But it ensures that different records within a complex, mulit-party system agree.
Super important because every good business decisions depends on accurate information.
If your books and records are not accurate, to jail with you.
It’s that important.
And we’re back at the house.
We covered most of what you’ll need to start your journey: basic definitions for every piece of the trade lifecycle. Details about trade execution… instruction capture… trade enrichment (taking those 7 make adding everything else you’ll need).. trade confirmation, Trade Settlement, Pre-settlement statuses, unmatched instructions, failed settlements, market-by-market differences, partial settlements, your books-and-records, and reconciliation.
Hope you learned something.