Chapter 12
The Trade Agreement and Settlement Processes
12.1 THE TRADE AGREEMENT PROCESS
Trade agreement is the process of the trade parties agreeing that orders have been executed in accordance with the ordering party’s wishes. Generically, trade agreement is designed to detect and correct executed orders where either:
- The party concerned recognises the trade, but disagrees one or more details (e.g. incorrect price, value date, etc.); or:
- The party concerned does not recognise the trade at all.
There are four commonly used methods of trade agreement:
- Mutual exchange of confirmations
- The confirmation, affirmation and allocation model
- Use of a central matching engine
- Confirmation followed by no further action.
12.1.1 Mutual exchange of confirmations
This method of trade agreement is mostly used to agree foreign exchange, money market loan and deposit and OTC derivative transactions.
There are a number of variants of this model, but the basic workflow is captured in Figure 12.1. In this workflow, Party A sends Party B a confirmation note that begins “We confirm our purchase from you of….” While Party B sends Party A a confirmation note that begins “We confirm our sale to you of….” It is up to both parties to read the confirmation from the other party and check that their trade details agree to its trade details. If they do agree, there is no need for any further communication between the parties; if they don’t agree, then one party takes the matter up with the other party.
Figure 12.1 Mutual exchange of confirmations
Confirmation messages may be sent by mail, fax or telex – in which case message comparison is a manual process.
In high volume environments confirmation messages are sent in electronic format (usually in SWIFT format) and each party normally uses a dedicated confirmation matching application to compare the message that it has sent with the message that it has received. If the two records agree, then these applications move the workflow on to next stage in the STP process, where the two parties send their settlement instructions to their settlement agents. If the two records do not agree then the results of the matching process are delivered to a workbasket or input screen where a user will investigate and take the necessary action to resolve the dispute. This method of trade agreement only covers the post-execution stage of the trade flow; it does not provide any facilities for comparing orders.
The relevant SWIFT messages for mutual exchange of confirmations are shown in Table 12.1.
Table 12.1 SWIFT messages used in mutual exchange of confirmations
| Message number | Message name | Additional information |
| MT300 | Foreign exchange trade confirmation | |
| MT305 | Foreign currency option confirmation | Confirms information agreed to in the buying and selling of vanilla options on currencies |
| MT306 | Foreign currency option confirmation | Confirms information agreed to in the buying and selling of exotic options on currencies |
| MT320 | Fixed rate loan and deposit confirmation | |
| MT330 | Call and notice loan and deposit confirmation | |
| MT360 | Single currency interest rate derivative confirmation | Confirms the details of a single currency interest rate derivative swap, cap, collar or floor |
| MT361 | Cross currency interest rate swap confirmation | Confirms the details of a cross currency interest rate swap transaction |
Trade agreement for OTC derivatives
Swaps and other OTC derivatives are agreed using this model. OTC confirmation messages (often referred to as contracts) are based on the ISDA master agreement which is a standardised contract (drafted by the International Swaps and Derivatives Association (ISDA). This master agreement contains general terms and conditions (such as provisions relating to payment netting, tax gross-up, tax representations, basic corporate representations, basic covenants, events of default and termination) but does not, by itself, include details of any specific derivatives transactions the parties may enter into. The ISDA master agreement is a pre-printed form which will not be amended itself (save for writing in the names of the parties on the front and signature pages). However, it also has a manually produced schedule in which the parties are required to select certain options and may modify sections of the master agreement if desired.
SWIFT format messages are available for OTC derivative confirmations, but due to the complexity and diversity of the transactions, printed confirmations that need to be read, interpreted and checked by qualified individuals are still extremely common. After confirmations are checked manually, they are then scanned into a database from where they may be retrieved if required. This variant of the mutual exchange model can be represented by Figure 12.2.
Figure 12.2 Manual agreement of OTC confirmations
Each year the ISDA conducts an operations benchmarking survey among its member firms. Some of the salient points concerning trade agreement that were discovered in the 2007 survey are shown in Tables 12.2–12.4.
Table 12.2 shows that a high proportion of outgoing confirmations was not dispatched until T + 2 or later. As most OTC trades have a value date of T + 2, this means that the recipient cannot possibly check the confirmations until after the trade has settled. This breaches the third principle of STP, which states:
Table 12.2 Promptness of dispatch of outgoing OTC confirmations
Trade processing should consist of a set of logical stages, each one being dependent on the satisfactory conclusion of the previous stage. No stage should commence until the previous stage has completed successfully.
Not surprisingly, the failure to send out and agree trade details on a timely basis results in a relatively high proportion of trades having to be amended, as shown in the Table 12.3.
Table 12.3 Percentage of trades that need to be rebooked as a result of confirmation checking
| Product | % of trades needing to be rebooked |
| Equity swaps | 15 |
| Interest rate swaps | 11 |
| Credit derivatives | 13 |
| Currency options | 6 |
The ISDA survey also asked respondents what levels of automation they had successfully applied to various processes. The responses to the questions concerning trade agreement processes were as found in Table 12.4.
Table 12.4 Level of automation of trade agreement – OTCderivatives
| Process automation | |
| Activity | % of firms that had automated this activity |
| Production and dispatch of confirmations | 56 |
| Imaging outgoing confirmations | 56 |
| Imaging incoming confirmations | 44 |
| Matching confirmations | 28 |
Trades that have been arranged by a money broker
If transactions have been arranged by a money broker (refer to section 7.8) then the money broker will also send both parties a confirmation; either in printed format or electronically. When it is sent electronically it is sent using a private telecommunications network operated by City Networks Limited on behalf of the Wholesale Money Brokers Association. This facility does not use SWIFT message formats; it has its own standards and APIs. When a money broker is involved, then Figure 12.1 is modified as shown in Figure 12.3.
Figure 12.3 Mutual exchange of confirmations with money broker involvement
The money broker also sends a confirmation note to both parties informing them that it has arranged the deal for them. Without the confirmation note from the money broker, both parties cannot start the transaction flow, as they are not yet aware that the deal has been completed. Most matching applications support three-way matching between the two trade parties and the money broker. Note that it is not necessary for Parties A and B to send a confirmation to the money broker, they only need to contact the money broker if the process results in a mismatch.
When building or buying a matching application, it is important to establish whether there is a business need to match money broker confirmations, as not all matching applications support this variant of the model.
12.1.2 The confirmation, affirmation and allocation model
This multi-stage process is the traditional process used to enable sell-side firms to agree trade details with buy-side firms when equities are traded (see Figure 12.4)
The steps on the process flow are as follows:
Figure 12.4 Confirmation, affirmation and allocation
1. The buy-side firm sends the order to the sell-side firm.
2. The sell-side firm acknowledges it, and makes a decision as to how to execute it – i.e. whether to fill it by placing it with an investment exchange and which exchange to route it to if there is a choice of exchanges; or whether to fill it by buying and selling from its own book. Article 21 of the MiFID regulations (see “The principles of best execution …”, page 65, Chapter 8) requires the sell-side firm to have an execution policy that ensures that similar orders are always treated in the same fashion.
3. The sell-side firm then executes it, either as a single transaction (also known as a block trade), or if the order is for a large amount by breaking it down into smaller amounts.
4. When the sell-side firm has completed the order, it sends a confirmation to the buy-side firm. The confirmation will include, inter alia, details of:
- The name of the client for whom the order was executed
- The name of the stock and whether it was bought or sold
- The trade date of the purchase or sale
- The value date of the purchase or sale
- The price of the trade – if the order was split into more than one order on an order queue this will be the average price of all the executed orders
- The net amount to be paid or received by the investor, including any fees and charges, and for a bond sale any amount of accrued interest on the deal
- Whether the firm acted as agent or principal
- If it acted as agent, the name of the exchange that the deal was executed on.
5. The buy-side firm then checks the confirmation received from the sell-side firm. If it disagrees the details, it takes the matter up with the sell-side firm, otherwise it is said to affirm the confirmation.
6. At the same time that the buy-side firm affirms, it also advises the sell-side firm of the allocation details of this order. The fund manager itself has placed this order on behalf of its own clients – there may be just one of them or there may be many. At this stage the fund manager notifies the sell-side firm of the details of who its clients are, and how many shares are to be allocated to each client.
7. The sell-side firm then splits the parent trade into a number of child trades, one for each investor, and reconfirms the allocations to the fund manager. The confirmation repeats the information in the original confirmation of the “parent” trade (4 above).
8. The buy-side firm then reaffirms each of the individual fund transactions.
9. Both the buy-side firm and the sell-side firm then issue settlement instructions to their settlement agents.
10. All of these communications may be automated in the same way that the original order was automated, i.e. the confirmations, affirmations and allocations may be transmitted by any of the following methods:
- By telephone or fax
- By entering the information into a secure web page provided by the sell-side firm
- By exchanging SWIFT messages
- By entering the affirmation and allocation details directly into the sell-side firm’s order management system. This, in turn, may be facilitated by using a third-party “hub and spoke” order routing service, which in turn usually involves exchanging FIX Protocol messages. Hub and spoke systems are provided by a number of vendors including Omgeo, Reuters and Bloomberg.
Figure 12.5, reproduced by permission of Omgeo LLC, shows how this is achieved using the Omgeo Oasys Global™ service provided by Omgeo LLC.
Step 1:
- The sell-side firm sends the confirmation of the block trade to the fund manager.
- If both firms are using Omgeo Alerts (see section 10.6.3) then the sell-side firm’s settlement instructions will be appended to the message.
Step 2:
- The fund manager accepts or rejects details of the block trade.
- It affirms or rejects contract notes individually.
- If the details are accepted, then allocations are sent.
- If both firms are using Omgeo Alerts, then the investment manager’s settlement instructions are appended to the allocation message.
Step 3:
- The sell-side firm accepts or rejects allocations individually.
- If accepted, then confirmation messages are created for each allocation.
Step 4:
- The fund manager affirms or rejects confirmation messages for each allocation.
- Copies of each confirmation message (if required) are generated.
Relevant SWIFT messages
The SWIFT messages shown in Table 12.5 are relevant to this model of order placing and trade agreement.
Table 12.5 SWIFT messages used in the confirmation/affirmation model
12.1.3 Use of a central matching engine
The traditional role of matching engines
Matching engines provide a further level of automation of the trade agreement process. They have been provided by investment exchanges and clearing houses for many years to automate the process of trade agreement between member firms. These traditional matching engines, however, have not been used by buy-side firms for a number of reasons.
The principles behind the traditional matching engines provided by exchanges and clearing houses are as follows:
1. Both parties input their trade details to the matching engine database in real time, as soon as possible after the trade has been struck. This is usually achieved by building a real-time interface from the firm’s relevant business application to the matching engine.
2. The matching engine then compares the two trade reports, and provides the matching results to both parties in real time (see Figure 12.6).
Figure 12.6 Central matching engine
Most matching engines also facilitate post-trade publication (also known as regulatory trade reporting). This is the process required in the EEA under the MiFID rules for post-trade transparency (see Chapter 8). Matching engines send a copy of each trade record to the regulator concerned so that it may monitor for insider dealing and market abuse. Because the regulators demand real-time trade reports, then trades need to be reported to the matching engine in near real time.
However, traditional matching engines did not connect exchange member firms with non-member firms, nor did they support the confirmation/affirmation/allocation model, and nor did they store SSIs.
In 2002, Omgeo LLC launched the Central Trade Manager™(CTM), a central matching engine that involves the buy-side community and also supports block trades and allocations. The functions of CTM are shown in Figure 12.7, which is reproduced by permission of Omgeo LLC.
Steps la and lb: After execution the sell-side firm sends a block/notice of execution (NOE) to their investment manager counterparty. The investment manager also sends their block and allocation messages to Omgeo CTM (this process is non-sequential). The sum of all the allocations have to agree to the total of the block trade confirmation. The investment manager can, optionally, send a block trade order first; if not, the system internally generates the block by grouping the allocation data.
Step 2: The fund manager and sell-side firm block trades are centrally matched.
Steps 3a and 3b: After the block trade is matched, allocations are sent to the sell-side firm for confirmation, after being enriched with standing settlement instructions via Omgeo Alert.
Step 4: To finalise the trade, the sell-side firm sends the allocation confirmations, Omgeo CTM matches them with the allocations and the trade moves to “match agreed” status.
Steps 5 and 6a: Throughout the process, status messages have been sent to the investment manager. This is done until a status of “match agreed” is achieved.
Step 6b: Once a matched status is achieved, an affirmation is also sent back to the broker/dealer.
Step 7: If required by either party, Omgeo CTM settlement notification functionality generates a SWIFT message based on the matched trades and then transmits the message to the settlement agent via SWIFT.
Step 8: Settlement of trades, including transfer of cash and securities, occurs at the local depository outside of Omgeo.
Message formats supported
The product supports a number of message standards, including SWIFT and FIX.
12.1.4 Confirmation followed by no further action
For private client (retail) trades, the executing firm simply sends a confirmation note by post or email to the client, who takes no action if it agrees with the contents.
12.2 COMMUNICATIONS BETWEEN THE TRADE PARTY AND ITS SETTLEMENT AGENT
12.2.1 Introduction
A settlement instruction is, as its name suggests, an instruction sent by a trading party to a settlement agent, instructing it to make or accept delivery of a financial instrument in exchange for receipt of payment of funds.
When the two trade parties have completed the trade agreement process, they both need to instruct their settlement agent to settle the trade. For an agency trade, the sell-side firm has to do this twice – first to settle the trade with the market counterparty, or stock exchange (the market-side trade), and second to settle the trade (the customer-side trade) with the investor.
If the market-side trade was for an instrument that is normally executed on a stock exchange order queue then there is no need to instruct it individually. The exchange concerned reports it to both the appropriate central counterparty, who novates it, and nets it with other trades in the same security; and also to the appropriate Central Securities Depository who will input settlement instructions for the net amount on behalf of both the firm concerned and the CCP. This concept was first examined in section 7.7.2, and is summarised in Figure 12.8.
Figure 12.8 Trade flow with central counterparty
For all other trades, each firm must send its settlement instructions for each individual trade to the relevant settlement agent. In this context “all other trades” includes:
- All trades for non-equity instruments
- Equity “market-side” trades in equities not normally traded on an order queue
- All “client-side” equity trades.
If the instruction relates to securities, and the delivery of the securities is to be inextricably linked to the receipt of funds, it is said to be a delivery-versus-payment or DvP instruction. If payment and delivery are not inextricably linked, then it is said to be free of payment, or FoP. DvP is the norm in the securities markets, as sending instructions FoP creates credit risk. For this reason, most firms have very strict rules as to under what circumstances an FoP instruction may be issued.
This means that many application systems that automatically generate settlement instructions are usually designed to require a second level of authorisation before an FoP instruction can be sent out. Each trade party will send its instructions to the settlement agent it has nominated for the particular asset class being traded. This information is stored in the SSI tables that were examined in section 10.6.
12.2.2 Contents of settlement instructions
Settlement instructions are precise commands, telling a settlement agent exactly what to do. No matter what message format is used, they follow a defined standard, which is illustrated in Table 12.6 for a principal trade.
Table 12.6 Contents of a settlement instruction
| Field name | Explanation of contents | Example data |
| From: | Identity of the firm sending this instruction (note 1) | ABC Investment Bank |
| To: | Identity of the settlement agent receiving this instruction (note 1) | Euroclear Brussels |
| Value date | Earliest date on which this instruction should be carried out | 5-Mar-07 |
| Deliver/Receive | Whether securities are to be delivered or received | Deliver |
| Settlement basis | Whether to deliver-versus-payment or free of payment | Versus payment |
| Quantity of securities | The number of shares (equity) or face value of bonds to be delivered | 1 000 000.00 |
| Security reference | The ID of the security being delivered or received (note 2) | ICI plc 5% bond maturing 28 January 2010 |
| Settlement currency | The currency of the cash to be paid or received | EUR |
| Net settlement value | The amount of cash to be paid or received | 985 000.00 |
| Our depot account | This firm’s stock account number with the settlement agent | 123456789 |
| Our cash account | This firm’s cash account number with the settlement agent | 987654321 |
| Counterparty depot details | Full details of the counterparty’s stock settlement account, including account code (note 3) | Société Généralé Paris, account no. 104867, in favour of Minicorp Pension Fund |
| Counterparty nostro details | Full details of the counterparty’s cash settlement account, including account code (note 3) | Société Généralé Paris, account no. 0-0876554332, in favour of Minicorp Pension Fund |
| Our reference | Our reference for this instruction. We would expect the settlement agent to quote this on all subsequent communications with us about this instruction | 123456-01-02-03 |
| Transmission date time | The date and time that the settlement instruction was sent | 01/03/2007 10:33 |
| Notes to Table 12.6: | ||
| 1. The identities of the sender and receiver are usually represented by a BIC code – see section 10.5.1. | ||
| 2. The identities of the other party and its settlement agent are usually represented either by BIC codes or CSD/ICSD participant codes. | ||
| 3. The identity of the security is usually represented by an ISIN code, SEDOL code, CUSIP code or some other standard identifier. The most widely used code in Europe is ISIN code – see section 10.4.1. | ||
12.2.3 Transmission of settlement instructions
Settlement instructions are usually transmitted in one of the following three ways:
- In the form of SWIFT messages – Table 12.11 in Section 12.2.9 for a full list of relevant messages.
- Using a proprietary standard message developed by the settlement agent, and transmitted using an “electronic banking system” designed by that settlement agent. Most commercial custodians, as well as the CSDs and ICS, supply systems to their customers that provide for secure communication. Traditionally, these were PC systems that required physical installation at the customer site, but increasingly these systems are web-based applications.
- Email, fax and telex: These traditional means of communication are being used less and less, as they do not lend themselves so readily to the STP concept as the other methods do.
In a high volume, STP-based environment the firm’s settlement system usually generates settlement instructions automatically, and communicates directly with the firm’s chosen method of transmission.
12.2.4 Information supplied by settlement agents between receipt of instruction and actual settlement event
Between the time that the settlement agent receives the instruction and the date that the trade actually settles, settlement agents usually send status messages relating to trades that are pending settlement to the firm concerned (see Figure 12.9).
Figure 12.9 Communication between trade party and settlement agent
The format of such a status message will be based on Table 12.7.
Table 12.7 Contents of a status message
| Field name | Explanation of contents | Example data |
| From: | Identity of the settlement agent sending this status message | Euroclear Brussels |
| To: | Identity of the firm receiving this status message | ABC Investment Bank |
| Our trade reference | Euroclear’s unique reference for this instruction | Kkee4455tt |
| Your trade reference | The reference that ABC quoted on the original settlement instruction | 123456-01-02-03 |
| Date and time of this message | The date and time that this message was sent | 02/03/200/09:00:00 |
| Brief details of the instruction | Action, security, security quantity, cash currency, cash amount | DvP 1 000 000 ICI plc 5% bond maturing 28 January 2010 to Société Généralé in favour of Minicorp for EUR 985 000.00 |
| Status code | A code to represent the status of the instruction | See below |
Status codes
Each settlement agent will issue its customers with a list of status codes and their meanings. There may be several hundred individual codes, but the common ones (Euroclear codes are used in this example) are as shown in Table 12.8.
Table 12.8 Explanation of status codes
| Code | Meaning | Action to be taken by firm |
| UNM0 | Unmatched – you have sent an instruction but your counterparty hasn’t. Trade isn’t due to settle until T + 2 or later | Take up with trade party |
| UNM1 | Urgent unmatched – As above, but trade is due for settlement tomorrow or earlier | Take up with trade party – as a matter of urgency |
| CUNM | A trade party has alleged a trade against you, but you have not sent any instruction | Investigate internally/take up with trade party |
| USEC | Trade is matched, but you don’t have any stock to deliver | Ascertain why you have no stock. Try to borrow if necessary |
| CSEC | Trade is matched, but counterparty has no stock to deliver | Take up with trade party |
| COLL | Trade is matched, but you don’t have sufficient credit in your account with the settlement agent to pay for the stock | Investigate why. If the cash is held in a different bank account, transfer it, or else negotiate a line of credit |
| OTH | Other reason why this instruction might not take affect – usually this means that the other party has insufficient cash or collateral in his account to pay for the stock | Take up with trade party |
| OK | The instruction is OK for future settlement | No action is needed |
Most CSDs and ICSDs make this information available to participants in real time; it is up to business applications in the firm’s configuration to access it. Some settlement agents make it available in real time, but others only send it in the form of a SWIFT message once each day, at the end of the day.
The status of a trade may change many times between the time that the instruction was received by the agent and the date and time that it actually settles. For example, the status history of this trade might be as shown in Table 12.9.
Table 12.9 Status message history
12.2.5 The process of settling the trade – settling within tolerance
The settlement agent will settle the trade provided that:
1. Value date has been reached.
2. The seller has the stock to deliver.
3. The buyer has the cash or credit to pay for it.
4. Both the buyer’s and the seller’s instructions have been received by the agent’s cut-off time for processing – this will usually be the close of business on the day before value date, or may be on value date itself depending on the market conventions for the instrument being traded.
5. The seller’s instructions match the buyer’s instructions. In determining whether instructions match, the settlement agent usually has the ability to settle within tolerance. That is to say, if the instructions match in every respect apart from a minor difference in the cash consideration, then the agent will settle the trade using the cash figure supplied by the seller. What is considered to be “a minor difference” varies from market to market; in the case of trades settling at Euroclear, for example, the threshold is set at the equivalent of USD 25.00.
A trade that has not settled by the agreed value date is known as a failed trade. The causes and consequences of failed trades are examined in Chapter 13.
12.2.6 Information provided by the agent when the trade settles
The settlement agent will provide the information shown in Table 12.10 when the trade settles.
Table 12.10 Contents of a settlement message
| Field name | Explanation of contents | Example data |
| From: | Identity of the settlement agent sending this status message | Euroclear Brussels |
| To: | Identity of the firm receiving this status message | ABC Investment Bank |
| Our trade reference | Euroclear’s unique reference for this instruction | Kkee4455tt |
| Your trade reference | The reference that ABC quoted on the original settlement instruction | 123456-01-02-03 |
| Date and time of this message | The date and time that this message was sent | 02/03/200/09:00:00 |
| Deliver or receive | Whether stock has been delivered or received | Deliver |
| Security reference | The ID of the security being delivered or received | ICI plc 5% bond maturing 28 January 2010 |
| Stock amount | Amount of stock actually delivered or received | 1 000 000.00 |
| Settlement currency | The currency of the cash that was received or paid | EUR |
| Settlement amount | The amount of cash that was received or paid | 985 000.00 |
Table 12.11 SWIFT settlement messages
12.2.7 The role of the unique reference number of the settlement instruction
When ABC sent the instruction, it provided its unique reference number (123456-01-02-03). Euroclear has quoted this number on all the messages it has sent back to ABC about this trade. The existence of this unique number facilitates STP; in particular it enables the update of the trade record in ABC’s systems with the latest status of the instruction.
Some settlement systems simply quote the trade reference number in this field. There are a number of reasons why this is not “best practice”, including the following:
1. Some trade types by definition will generate two or more instructions for different “events”. For example, a stock loan – refer to Chapter 21 for more information – might generate the following event-based instructions:
- An initial DvP instruction to settle the start leg
- One or more (cash only) margin payments or refunds of margin payments as price movements create the need to increase or reduce collateral
- One or more (cash only) interim payments of fees if the loan crosses several month ends
- A final DvP instruction to close the transaction, returning the stock and the cash collateral.
While an agency trade always has two components that settle independently of each other – the customer-side trade with the investor and the market-side trade with the exchange or market maker.
2. Sometimes it may not be possible to settle the whole transaction in one operation. The parties may agree to accept partial delivery in return for partial payment.
3. The affect of settlement netting – sometimes several trades will be consolidated into a single settlement.
4. If errors are made in trade processing, then sometimes settlement instructions need to be cancelled and reissued. Therefore a single trade has gone through multiple trade versions, each one creating changed settlement instructions.
For these reasons, it is generally considered “best practice” when designing a settlement system to have a many (trades) to many (instructions) relationship between trades and settlement instructions. As a result, many settlement applications build a unique reference number for a settlement instruction using this type of methodology:
| Trade number | 123456 |
| Event number | 01 |
| Partial settlement number | 02 |
| Version number | 03 |
Therefore the unique instruction for the third version of the second partial settlement instruction for the first event of trade number 123456 would be 123456-01-02-03.
12.2.8 Potential problems caused by the use of ISIN codes in status and final settlement messages
In section 10.4.1 we learned that an individual security may have a single ISIN code but many SEDOL codes or combinations of ISIN code and market identifier code. Therefore there may be a problem in interpreting messages from settlement agents when they only quote the ISIN code on these messages – the application processing the message does not know which unique security the message refers to. Therefore such applications need to provide an exception path that enables the correct security to be allocated by manual intervention.
12.2.9 Relevant SWIFT messages concerned with settlement
Note that the MT548 and the MT537 messages essentially provide the same information. The MT548 provides the information about a single instruction, while the MT537 provides the information for all the unsettled instructions for a particular account.