Operational Overview of the
Real-Time Transaction Reporting
System for Municipal Securities
Municipal Securities Rulemaking Board
April 2003
1
NOTE
REVISIONS AFTER APRIL 2003
The Operational Overview published in April 2003 was altered in
certain respects by the revised system specification, Version 1.1,
published in September 2003. In particular, Version 1.1 changes the
Overview regarding storage of trade data in RTTM and RTRS and the
RTRS e-mail messages to dealers showing acceptance of inter-dealer
trades into the regulatory database.
Please refer to the latest version of the specifications for the most
current Operational Overview.
2
2
NOTE
This Operational Overview is provided for municipal
securities dealers who are required to report transactions to
the MSRB. It highlights new and changed features needed
for real-time reporting of municipal securities.
Publication of the Operational Overview will be followed
by a specification that will provide field-by-field
definitions for real-time transaction messages.
The MSRB’s real-time reporting system is designed to
work together with the Fixed Income Clearing
Corporation’s Real-time Trade Matching system. The
reader is assumed to be be familiar with the FICC system.
Documents describing that system are cited below.
3
THE ANNOTATED BRIEFING FORMAT
This document is presented as an annotated briefing made
of PowerPoint slides and textual annotations. The slides
are similar to those presented in briefings to dealers in five
cities during April 2003.* The annotations provide
detailed or extensive information that is more suited to text
than to slides.
There are three Appendixes, linked to the main document
by hyperlinks in the last slide. These are also provided as
three separate files that can be accessed by the reader.
*See “Real-time Transaction Reporting: Joint Seminar
Announcement,” MSRB Notice 2003-5 dated February 26,
2003, on www.msrb.org.
4
Executive Summary
5
Why Real-Time Reporting?
• MSRB has been committed to comprehensive,
contemporaneous transaction reporting since 1994.
• Since 1994, MSRB has implemented transparency in
incremental steps.
• Real-time reporting is planned to begin in mid-2004.
6
What is Real-Time Transaction
Reporting?
In the real-time environment, dealers will be
required to report all municipal securities
transactions within 15 minutes.
7
MSRB’s Objectives for Real-Time
Reporting
• To have the operational details function as smoothly as
possible for dealers.
• To collect real-time trade data at the lowest possible
cost to dealers.
• To maintain consistency with current municipal
operations and related markets (e.g., corporate bond
reporting).
8
Basics of Real-Time Reporting
• RTTM/RTRS – Two new systems -- the automated comparison
system and the regulatory reporting system -- will dovetail so that
one submission will serve for real-time street-side comparison and
regulatory reporting.
• ISO-15022 – This international standard file format will serve for
comparison and reporting.
• RTTM Web – A web interface will be available for real-time
submissions and corrections.
9
Schedule
• Operational overview and specifications-April 2003.
• Draft dissemination plan and proposed rule changes
for comments mid-2003.
• Dealer testing late 2003.
• RTTM available to NSCC participants 4th quarter
2003; RTRS operational mid-2004.
10
FURTHER INFORMATION
RTRS documentation includes:.
“Real-Time Reporting of Municipal Securities
Transactions,” MSRB notice dated May 29, 2001, on
www.msrb.org.
“Plans for MSRB’s Real-time Transaction Reporting
System,” MSRB notice 2003-3 dated February 3, 2003, on
www.msrb.org.
“Specifications for Real-time Reporting of Municipal
Securities Transactions,” to be published in April 2003.
Draft plan for dissemination of prices in real-time, with
proposed rule changes, to be published in mid-2003.
Test plan for RTRS users, to be published in late 2003.
User’s manual for RTRS, to be published in 2004.
11
Operational Overview
12
Topics
•
•
•
•
•
•
Prospective reporting rule
General features of real-time reporting
Matching and regulatory reporting
Business aspects of real-time reporting
Reporting procedures
Technical and operations aspects
13
Prospective Reporting Rule
• MSRB plans to require dealers to report all
transactions in municipal securities within 15
minutes of the time of execution
• Each party to a comparison-eligible inter-dealer
transaction will be required to submit, within 15
minutes, all information required for automated
comparison to occur in the Real-time Trade
Matching system (RTTM)
14
General Features of Real-Time Reporting
• Trade input will be formatted as messages with interactive
feedback
• All trade messages go first to FICC’s Participant Access
Network for timestamp, format checking and routing
• To report a customer trade:
– The dealer sends an “Instruction” message to RTRS
– RTRS sends an acknowledgement or error message to dealer
– If there is an error, the dealer sends a Modify message or a Cancel
message plus new Instruction to RTRS
FICC = Fixed Income Clearing Corporation (DTCC subsidiary)
RTRS = MSRB’s Real-time Transaction Reporting System
15
DEFINITIONS AND REFERENCES
FICC: The Fixed Income Clearing Corporation. FICC
formerly was the Government Securities Clearing
Corporation (“GSCC”), a subsidiary of Depository Trust
Clearing Corporation.
Participant Access Network: FICC’s full, secure, TCP/IP
network providing access to RTTM and other FICC
services. See New Service Bulletin dated June 3, 1998 on
www.gscc.com, in the Important Documents section, under
Other Important Documents.
RTTM: The FICC’s Real-Time Trade Matching system.
See Interactive Messaging : NSCC Participant
Specifications for Matching Input and Output, Version 1.0,
dated March 31, 2003, on www.nscc.com, in the Important
Notices section, under Features.
RTRS: The MSRB’s Real-time Transaction Reporting
System. See “Plans for MSRB’s Real-time Transaction
Reporting System,” MSRB notice 2003-3 dated February 3,
2003, on www.msrb.org.
16
General Features of Real-Time
Reporting (continued)
• For inter-dealer trades, a single initial record will
serve for comparison and regulatory reporting
• The NSCC participant will submit the initial
record
• RTTM will pass the the initial record’s data to
RTRS
17
General Features (continued)
• This approach results from the “dovetailing” of
the new automated comparison system (RTTM)
and the new regulatory reporting system (RTRS)
• Dealers will use the single record to satisfy two
MSRB requirements:
– Rule G-12(f) – automated comparison
– Rule G-14 – transaction reporting
18
Preview of the Next Slides
• The following slides show:
– Each participant submitting a trade instruction to FICC
– FICC acknowledging the instructions
– FICC advising each party of the contra party’s
instruction
– FICC sending copies of both instructions to MSRB
19
Trade Submission
Member
Firm
1. MT 515/Instruct
FICC
20
Trade Submission
Member
Firm
1. MT 515/Instruct
FICC
2. MT 515/Instruct
MSRB
21
Trade Submission
Member
Firm
3. MT 509/Ack
4. MT 518/Advisory
1. MT 515/Instruct
Contra
Member
5. MT 515/Instruct
FICC
2. MT 515/Instruct
MSRB
22
Trade Submission
Member
Firm
3. MT 509/Ack
4. MT 518/Advisory
1. MT 515/Instruct
Contra
Member
5. MT 515/Instruct
FICC
2. MT 515/Instruct
6. MT 515/Instruct
MSRB
23
Acknowledgement of Street Trades
• RTTM acknowledgement will serve as
acknowledgement for regulatory purposes also, if
no regulatory errors found by RTRS
• If RTTM matches two sides, reprices the trade, or
deletes an unmatched side, it will notify
RTRS,which will track these changes for
regulatory purposes
• If RTRS finds errors, it will notify the participant
and the effecting dealer
24
Preview of the Next Slide
• The next slide shows that, after FICC matches
two sides of a trade:
– FICC advises each participant of the match
– FICC advises MSRB of the match
25
Trade Submission
Member
Firm
Contra
Member
9. MT 509/MATCH
10. MT 509/MATCH
FICC
11. MT 515/Match
12. MT 515/Match
MSRB
26
Actions of Two Systems (Street Trades)
• If RTTM…
• Then RTRS…
– Rejects your side submitted
for matching
– Will not send you any
message
– Accepts and acknowledges
your side
– Will not acknowledge an
error-free side, but…
– will send a you a message
if your side is late or has
errors
27
Actions of Two Systems
Trades)
• If RTTM…
– Has sent your trade to
settlement and purged it,
then receives your
modification of regulatory
data, finds no format errors
in your message, and
therefore forwards it to
RTRS
(Customer
• Then RTRS…
– Will acknowledge an errorfree side, or
– Will send a you a message
if your side is late or has
regulatory errors
28
Business Aspects of
time Reporting
Real-
Street and Customer Trades
29
Trades that Must Be Reported
• Customer trades
– Trades in any issue that has a CUSIP assigned by
Standard & Poor’s
• Inter-dealer trades
– All street trades that are eligible for comparison. This
includes same-day and next-day trades.
30
Inter-Dealer Trades that Must
Reported
Be
• Principal trades between a clearing broker/participant and
its correspondent will continue to be compared and
reported using a single record (required by rules G-12 and
G-14)
• The same is true for trades between two correspondents of
one clearing broker (required by rules G-12 and G-14)
• MSRB will require regulatory reporting of “transactions”
between an NSCC participant and its fully disclosed
introducing broker - similar to an NASD TRACE
automatic give-up (AGU). Procedures described below.
31
Inter-dealer Trade Exceptions
• Per NSCC rules, trades in when-issued short-term
notes are not eligible for comparison
• Therefore, they are not subject to regulatory
reporting to the MSRB
32
Dealer Capacity as Agent or Principal
• The dealer will report whether it did a street trade
as the agent for a customer or as a principal
– In bilateral trades, dealer reports only its own capacity
– In unilateral* trades, the dealer reports its own and the
contra party’s capacity
– A new field is available in the RTTM message format
– Brokers’ broker trades will be reported as “principal”
trades
*“Unilateral” trades and reporting procedures for dealer capacity are described below.
33
Time of Trade
• In the real-time environment, report the time of
trade to the second
• Trade date and time are in the same SWIFT field
but will be stored separately
• The input format for trade date and time is:
YYYYMMDDHHMMSS
• For time of trade on syndicate allocations, see the
note on the next slide
34
TIME OF TRADE FOR SYNDICATE
ALLOCATIONS
Current Rule G-14 reporting procedures state:
Q: What is the time of trade for syndicate allocations on
new issues?
A: First it should be noted that the "initial trade date"
for an issue of municipal securities cannot precede the date
of award (for competitive issues) or the date that the bond
purchase agreement is signed (for negotiated issues). See
rule G-34(a)(ii)(C)(2) and MSRB Interpretations of April
30, 1982, MSRB Manual and October 7, 1982, MSRB
Manual. Similarly, the time of trade may not precede the
time of award (for competitive issues) or the time that the
bond purchase agreement is signed (for negotiated issues).
In the typical case involving a competitive issue in which
allocations are made after the date of award, the time of
trade execution is the time that the allocation is made. If
allocations have been "preassigned," prior to a
competitive award, or prior to the signing of a bond
purchase agreement, the time of award or signing of the
bond purchase agreement should be entered as the "time
of trade." (Emphasis added.)
35
Correspondent of a Correspondent
• As currently, every trade must include the identity
of the dealer that effected the trade
• Usually, this is the NSCC participant or its direct
correspondent
• In some cases, the dealer that effects the trade is a
correspondent of a direct correspondent
• In such cases, all three dealers’ IDs must be
reported
36
Correspondent of a Correspondent –
Example of One Side
• NSCC participant:
• 0123
• Direct correspondent of
participant:
• ABCD
• Effecting broker
(correspondent of of
ABCD):
• WXYZ
37
Special Price Trades
• NASD Regulation has asked that reports of muni trades,
like corporate trade reports, indicate “special prices”
• A special price is an execution price impacted by a special
trade condition, such as trading a bond with interest when
it is currently trading flat by market convention
• “Special Price” does not impact comparison and
subsequent settlement
Note: “Special Price” is a different term than “Special Trade,” which is
used in FITS to indicate trading conditions as part of the contract
38
Special Prices (Continued)
• If trading at a special price, enter a reason code:
R001
R002
Special price because traded flat
Settlement other than Regular Way impacted
price
R003
Multiple reasons for special price
R004
Other
“Other” might include, for example, a transfer from an
accumulation account to a UIT
• Weighted Price trades must also be reported,
using the “Type of Price” field
39
Other Aspects of the 15-Minute
Reporting Requirement
• Firms will need to obtain, within 15 minutes:
– CUSIP numbers for new issues
– Pertinent price information for RW calculation
• Allocated syndicate trades need to be reported
quickly (see note on next slide)
• Corrections to incorrectly reported data are
required as soon as possible
40
REPORTING SYNDICATE ALLOCATIONS
As noted above, for allocated syndicate trades,
the time of trade is the later of the time when
allocations are made or the time of BPA
signing/time of award.
41
Transaction Reporting Procedures
42
Reporting Dealer Capacity
• In the real-time environment, dealers must report
the capacity of the effecting dealer in every trade
• Inter-dealer trades may be done as principal or as
agent for a customer
43
EXAMPLES OF AGENCY TRADES
Examples below show how agency street trades and
customer trades will be reported. In each example:
 Rectangles depict dealers
 Triangles depict customers
 Arrows depict trades
In example I below, Dealer A sells as principal and Dealer
B buys as principal. In example II, A also sells as principal
but B buys as agent.
In examples IV and V, Dealer A buys from a customer and
sells to another customer – in IV as principal, and in V as
agent.
Examples of many additional trade relationships are shown
in Appendix B.
44
Examples Showing Capacity
A
B
C
I
IV
C1
A
C2
45
Inter-Dealer Regulatory Only (IDRO)
Report
• As noted, a new regulatory only report (like an NASD
AGU) will be required for sales from a clearing broker’s
inventory. In this case:
– The sale is done by a fully disclosed introducing broker, as agent
– No principal position passes to the introducing broker
• Comparison is not required. The IDRO report is not
processed by RTTM. It is used for regulatory purposes
only, that is, audit trail construction.
• Examples follow: charts III and IIIb (also IIIa, in
Appendix B). Note: Iia is not an IDRO; it requires
comparison.
46
EXAMPLES OF INTER-DEALER REGULATORY
ONLY REPORTS
Examples III and IIIb on the following slide show interdealer regulatory only reports.
III. Dealer E, a correspondent of Dealer B, sells as
agent from Dealer B’s inventory
IIIb. As in example III, Dealer F sells from Dealer E’s
inventory. However, here Dealer F is a
correspondent’s correspondent.
Note that example IIa is not an IDRO. Here there is an
inter-dealer trade between Dealer A and Dealer F, which
must be compared and which Dealers A and B must clear.
47
Examples Showing Agency Trades & IDROs
48
IDRO (continued)
• An IDRO is reported as a unilateral submission
• Either the clearing broker or its correspondent
may report the IDRO
• For the IDRO shown in example III, report as
though it was a street trade:
Dealer
B
E
Capacity
principal
agent
Type
sold
bought
• Also report a customer sale by Dealer E as agent
49
IDRO (continued)
• The dealer that submits the IDRO unilaterally will
have accurate information about both sides and
will report the capacity of both sides.
• If necessary, the dealer that did not originally
submit the report may correct its side’s details.
50
Other Equivalents to Give-ups
and AGUs
• A typical street trade effected by a correspondent is
equivalent to a TRACE give-up. The NSCC participant
“gives up” the identity of its correspondent. (See Appendix B
example III and all of page 2.)
• Any unilateral* street trade submission is equivalent to an
AGU: Syndicate takedown, qualified service
representative (QSR), IDRO
• The dealer that submits unilaterally must report the
capacity of the contra party
* See next slide for notes on “unilateral submission”
51
UNILATERAL SUBMISSIONS
FICC defines RTTM submissions as “bilateral” or
“unilateral.”
Bilateral – Submission by buyer and seller of trade details
that match. This is the primary submission and matching
mode for participant-to-participant trades.
Unilateral – One approved party submits input for both
sides. The contra party has the option of submitting a
matching side. Unilateral submissions for municipal
securities include demand submissions by syndicate
managers and locked-in submissions by qualified service
representatives (QSR).
See Real-time Trade Matching (RTTM) for NSCC-Eligible
Fixed Income Securities: Business Requirements, July
2002, page 19, on www.nscc.com, in the Important Notices
section, under Features.
.
52
Third-Party Investment Advisor (IA)
Scenario – An illustration
• Broker A arranges for a third-party IA to manage
customers’ muni portfolios
• The IA buys a block of bonds from Broker B with
instructions to deliver some or all to Broker A
• IA then instructs Broker A on individual
allocations to each portfolio
53
Third-Party IA Scenario (continued)
• How to handle trade reporting
– Broker B reports one customer transaction, its block
size and price
– Delivery from Broker B to Broker A should not be
processed through the comparison system
– Broker A does not report customer transactions
54
Principles Regarding Who Can
Change Data
• The dealer that effects a trade is responsible for reporting
it in 15 minutes and for making any needed corrections as
soon as possible
• Match data on street trades is “owned” by the participant
• The dealer that effects the trade can change that trade’s
regulatory data in RTRS
Match data: Participant (buyer/seller), trade date, CUSIP, par, price, etc.
Regulatory data: Correspondent dealer symbols, time of trade, commission, capacity,
yield for dollar price trades, etc. See Appendix A for a complete list.
55
Changing Match Data and Regulatory
Data in Street Trades
• Match data can be changed only pursuant to
NSCC rules
• In the real-time system, regulatory data is more
amenable to change, pursuant to MSRB rules.
• The correspondent can change the regulatory data
on its street trade in real time
56
Street Trade Regulatory Data is
Separately Stored in RTTM and RTRS
• Customer trade data is stored only in RTRS
(because all customer data is regulatory)
• Street data is stored in both RTTM and RTRS
– Match data (comparison data) is identical in the two
systems. Only the participant may input or update this
data.
– Both dealers must coordinate to keep regulatory data
identical in the two systems
– RTRS will notify each party if the other changes
regulatory data
57
Who May Change Data
Participant Actions
Customer trade:
Any input for a trade it
effected
For its correspondent’s trade,
any input, if designated as
submitter by correspondent
Street trade:
Initial input for own or
correspondent’s trade
Changes to comparison data
Correspondent Actions
Customer trade:
Any input for its own trade
Street trade:
(No initial input of the trade)
(No changes to comparison
data)
58
Who May Change Data (continued)
Participant Actions
Street trade:
Correspondent Actions
Street trade:
Changes to regulatory data stored
in RTTM. (These changes will
not be stored in RTRS.)
(No changes to RTTM data)
Changes to regulatory data in
RTRS
Changes to regulatory data in
RTRS
Note that participant and
correspondent must
coordinate changes to
regulatory data in the two
systems.
59
How to Modify or Cancel Trade Reports
• Street trades:
– Any data except CUSIP and market of execution may
be changed on submission date, before the trade is
matched (per NSCC rules)
– Any incorrectly reported regulatory data may be
changed after match or after submission date
– The participant and the contra party may reverse a
matched trade via RTTM (per NSCC rules)
– For regulatory (audit trail) purposes, participants must
enter the control number of the trade being reversed.
60
How to Modify or Cancel (continued)
• Customer trades:
– Any incorrectly reported data may be modified except
dealer, CUSIP and trade date. (If these are wrong,
cancel and resubmit.)
– Modifications can be made for up to 90 days after trade
date
– No reversal procedure
• Inter-dealer regulatory-only
– Handled like customer trades
61
RTTM Web
• The RTTM Web is provided to supplement
messaging (MQ)
• RTTM Web is intended for:
• Low-volume trade submission
• Changes to trades submitted by MQ
62
Use of RTTM Web for Trade Data
• RTTM Web provides a common data entry screen for
FICC and MSRB data
• Participants may enter street trades through RTTM Web
• Correspondents or their agents (“submitters”) may enter
customer trades
• Through settlement date + 5, RTTM Web allows the
dealer to:
– View comparison data
– Change comparison data per NSCC rules (participant only)
– View RTRS regulatory data
“Submitter” is the participant or service bureau that submits customer data.
63
RTTM Web Screens, Trade Entry
64
Use of RTTM Web (continued)
• FICC provides an “affirmation” function on
RTTM Web which resembles the stamping of
advisories in FITS
• MSRB requires the dealer to enter regulatory data
(e.g., capacity) and to verify data entered by its
contra party (e.g., time of trade) when affirming a
trade. The dealer is responsible for its data.
65
Error Message Process
• Error message indicates “no errors found” by
RTRS or contains error codes (up to 7 codes)
• Each error indicates that the trade is
– Unsatisfactory (U) for regulatory reporting purposes
• Example: Price and yield are both missing from cust trade
– Questionable (Q)
• Example: Time of trade before 0600 hours
– Satisfactory (S)
• Example: No errors found
66
Error Correction Process (continued)
• The dealer must respond to “Unsatisfactory”
messages with a Modify message [preferred], or a
Cancel and new Instruct.
• Dealer must respond to a “Questionable” message
if the trade was incorrectly reported
– Example: Yield reported as 31.0 %, should be 3.10%
• Dealer need not respond to “Q” message if trade
was correctly reported
– Example: Yield computed per rule G-15 should be
31.0% on customer confirmation
67
Use of Control Numbers
• There is a unique dealer’s reference number (XREF) on
each transaction
– Street trade: XREF is unique for the participant
– Customer trade: XREF is unique for the effecting dealer
• RTTM and RTRS also assign a reference number
– RTTM TID for street trades (replaced by Match TID after match
is made)
– RTRS RCN (regulator control number) for customer trades
• The dealer has the option of using either the XREF or the
RTTM/RTRS number to refer to trades for cancellation,
regulatory modification or regulatory reversal crossreferencing. This is consistent with RTTM and TRACE
procedures.
68
Technical and Operations
Aspects
69
Single Pipeline
• FICC provides a single connection which
supports message submission for automated
comparison and regulatory reporting
• RTTM Web is an alternative
70
Message Structure and Data Fields
• The SWIFT standard 15022 message format will replace
proprietary formats
• FICC and MSRB are publishing detailed specifications
– MSRB Specifications will be posted on www.msrb.org in April
2003
• Data fields
– Most fields are currently in use, although some are new or have
new uses
– MSRB specification will describe how to use each field
– Full list of fields for municipal securities is in Appendix C.
71
Differences in Data Fields from Current
System
• Report commission or concession amounts in
total dollars (not as a rate)
– Example: If commission is .05 per $100 par, for a 10bond trade, report $5.00
• An ATS identifier will be required when dealer
uses ATS
– The ATS symbol will be assigned by MSRB
• An “originator” identifier will be required to
identify the party reporting customer trades, or
reporting any trade to MSRB on RTTM
72
Data Field Differences Already
Discussed
• Use of Dealer’s Reference Number (XREF) for
street trade
• Modification of street trade data using Previous
Reference Number
• Correspondent’s correspondent (COCO)
• Street trade as agent for customer
• Special price reason, weighted price
73
Use of Destination Indicator
The message has a repeating field in its body -required to tell the RTTM router where a record
should be directed. Participants must indicate
whether they want their trades to go to:
RTTM only (/DEST01) (Rarely used)
MSRB only (/DEST02)
RTTM and MSRB (/DEST01/DEST02)
The message also has a “Receiver” field in the header.
74
“Destination” and “Receiver”
Sending To:
“Destination”
Data in Body
“Receiver” Data
in Header
RTTM only
(rarely used)
/DEST01
NSCCTRRS
MSRB only
(regulatory only)
/DEST02
NSCCREGO
RTTM and MSRB /DEST01/DEST02
NSCCTRRS
75
Hours of Operation – Trades after Hours
• RTRS and RTTM hours will be identical
– 8 PM cutoff
• Input will not be scored “late” if trade is done
after cutoff and reported in a timely manner by
dealer(s)
• Example: Trade is done at 6 PM PST (9 PM EST)
on Monday
– Report the trade date/time as Monday, 2100 hours
– Report the trade (put on MQ queue) Monday or within
first 15 minutes of operation Tuesday
76
Testing
• Dealer testing will begin late in 2003
• Each dealer registered with the MSRB will need
to test successfully before mid-2004
• RTRS testing will be coordinated with RTTM
testing
– Dealer may test with both systems or with RTTM first,
RTRS later
77
Transition
• A dealer will transition from batch to real-time
reporting after passing test
• A dealer may voluntarily start submitting street or
customer trades in RT before mid-2004
• Dealers must be prepared to submit street and
customer trades in real-time by mid-2004
78
Appendixes
A. Regulatory fields changeable by effecting dealer
B. Detailed examples showing how to report dealer
identities
C. MT515 data fields for municipal securities
reporting
79