SEC Division of Trading and Markets no-action letter: Society for Worldwide Interbank Financial Telecommunication

UNITED STATES

SECURITIES AND EXCHANGE COMMISSION

WASHINGTON, D.C. 20549

DIVISION OF
TRADING AND MARKETS
Charles Llewellyn, Esq.
Regional Legal Counsel - Americas
SWIFT
7 Times Square, 45th Floor
New York, NY 10036
Re: No-Action Request ofthe Society for Worldwide Interbank Financial Telecommunication Dear Mr. LLewellyn, In your letter dated May 27, 2010, the Society for Worldwide Interbank Financial Telecommunication ("SWIFT') requests assurances that the staff ofthe Division of Trading and Markets ("Staff') would not recommend enforcement action to the Commission ifbroker-dealers use certain electronic messaging services offered by SWIFT ("SWIFT Messaging"), as more fully described in your letter, to satisfy their trade confIrmation obligations pursuant to Rule 1Ob-l 0 under the Securities Exchange Act of 1934 (the "Exchange Act"). Based on the facts and representations set forth in your letter, and without necessarily concurring in your analysis, the Staff will not recommend enforcement action to the Commission under Rule 1Ob-l0 ofthe Exchange Act against broker-dealers that use on SWIFT Messaging to confirm transactions as required by Rule 10b-l0 under the Exchange Act. In particular, we note that many users of SWIFT are U.S.-registered broker￾dealers ("Broker Users") that currently use SWIFT Messaging to communicate a range of information with other users. SWIFT represents that permitting Broker-Dealer Users to use SWIFT Messaging to send the confirmations required by Rule 10b-10 ("Confirm Messages") to institutional customers that are also users of SWIFT ("Customer Users") will enable parties to eliminate duplicate systems, thereby improving the efficiency and reliability of confirmation delivery and receipt processes. SWIFT also represents that the standardized format ofConfirm Messages would reduce trade reconciliation errors and

Charles Llewellyn, Esq.
May 27,2010 operational risks and increase the speed at which trades may be processed and settled. In addition, we note that:

• The Customer User will be obligated under SWIFT's rules to log on to
  SWIFT on each ofthe Customer User's regular business days and retrieve all SWIFT messages, including Confirm Messages, stored in the Customer User's queue.
• The Confirm Message will contain all the information required by Rule lOb￾lOin a machine-readable format.
• The Broker User may rely on a Confirm Message to satisfy its Rule IOb-IO
  obligations only ifsuch Confirm Message is sent to the person to whom the Broker User is required to direct the confirmation under Rule 10b-IO.
• The Broker User will obtain the prior written, informed consent ofthe
  Customer User (which may be electronic) to the receipt oftrade confirmations electronically using SWIFT's Confirm Messages.
• Upon the specific request of the Customer User, the Broker User will provide
  the Customer User with a paper copy of any trade confirmation sent by the Broker User to the Customer User using SWIFT's Confirm Messages during the two years prior to the date ofthe Customer User's request. Further, Broker-Dealer Users will retain the obligation to make and preserve confirmations in accordance with Rules 17a-3 and 17a-4 under the Exchange Act, as well as ultimate responsibility for compliance with Rule lOb-I O. This response represents a staff position regarding enforcement action only, and does not purport to express any legal conclusions with respect to the applicability ofthe statutory or regulatory provisions ofthe federal securities laws or any self-regulatory organization rules to SWIFT or its users. Moreover, this response is based upon the facts presented and the representations you have made, and any different facts or conditions might require a different approach. Finally, we note that the Commission has established criteria for the use of electronic media to satisfy obligations under Rule IOb-l 0,1 and we have expressed our See Use ofElectronic Media by Broker-Dealers, Transfer Agents and Investment Advisersfor Delivery ofElectronic Information, Exchange Act Release No. 37182 (May 9, 1996).

Charles Llewellyn, Esq. views about the application ofthese criteria to various fact patterns.2 Accordingly, having stated our views, we will no longer respond to letters in this area unless they present novel or unusual issues. Sincerely, ~<'2.-Cb~5_ Paula R. Jenson / . Deputy Chief Counsel See, e.g., Letters re: SS&C Technologies, Inc. (pub. avail. Aug. 13, 2008); SunGard Institutional Brokerage, Inc. (pub. avail. July 3,2007); Omgeo LLC (pub. avail. Dec. 14,2006) (supplemented by letter pub. avail. Mar. 12,2008); TradeWeb LLC (pub. avail. July 22, 2003); MBS Clearing Corp. (pub. avail. June 27, 1997); Thomson Financial Services, Inc. (pub. avail. Oct. 8, 1993); The Depository Trust Company (pub. avail. Oct. 29, 1974)(supplemented by letters pub. avail, Feb. 28, 1983 and Apr. 17,2001 (transfer ofTradeSuite service to Omgeo)). 2

May 27,2010
Securities Exchange Act of 1934/
Rule 10b-10
Deputy Chief Counsel
Division of Trading and Markets
100 F Street, N.E.
Washington, DC 20549
Re: Electronic Trade Confirmations Using SWIFT Messaging Services Dear Ms. Jenson:
We are writing to request your assurance that the staff of the Division of Trading and Markets of the Securities and Exchange Commission (the "Commission") would not recommend that the Commission take any enforcement action against broker-dealers that use certain electronic messaging services offered by the Society for Worldwide Interbank Financial Telecommunication ("SWIFT") to satisfy their trade confirmation obligations pursuant to Rule 1Ob-1 0 under the Securities Exchange Act of 1934 (the "Exchange Act"), as more fully described below.
I. Description of SWIFT.
SWIFT is a cooperative society that provides its users ("Users") with a comprehensive range of end to end messaging services and interface software that support every aspect of global financial services, payments, processing and reporting. SWIFT is organized under Belgian law and is owned and controlled by its member-shareholders, which include over 2,300 financial institutions in 209 countries. The SWIFT user base exceeds 9,300 connected Users. SWIFT's activities are not regulated, but given its systemic importance for worldwide financial systems and communications, SWIFT is overseen by the central banks of the Group ofTen countries. SWIFT has entered into a protocol with the National Bank of Belgium ("NBB") pursuant to which NBB acts as lead overseer. Under the terms of this protocol, the oversight of SWIFT focuses primarily on the security, operational reliability, business continuity and resilience of the SWIFT infrastructure. l This oversight does not grant SWIFT any certification, approval or authorization.

May 27,2010
II. SWIFT Trade Confirmation Messaging Services.
SWIFT has for several decades been a leading global financial messaging firm that offers Users a wide range of network, standards and application solutions supporting the operations of banks, securities firms and fmancial institutions worldwide. These solutions include a proprietary, secure network and numerous standards and messaging services that facilitate the straight-through transaction processing of customer payments and checks, foreign exchange transactions, securities transactions, collections, cash letters, treasury market transactions, documentary credits and trade finance and reporting/reconciliation messages. SWIFT's messaging service ("SWIFT Messaging") allows Users to exchange proprietary data with each other in a secure and reliable way by use of interface software that integrates with their in-house applications? SWIFT constantly seeks to expand SWIFT Messaging, which now includes a broad array of messaging standards and services that are typically utilized by the securities industry. In providing such messaging services, SWIFT solely transmits the message; it does not hold or transfer funds or securities, carry or manage accounts or execute trades on behalf of Users. One of the standardized message formats that a User may use to communicate with another User using SWIFT Messaging has been designed to confirm the terms of a securities transaction.3 In order to send a message using this template (a "Confirm Message"), a User must submit the necessary information, in the proper format, to a secure interface on the User's premises. Typically, a User will program its internal systems to automatically translate the relevant trade details and other information residing on those systems into the proper format and transfer such information to the secure interface.4 This secure interface will not accept a Confirm Message unless the required information has been submitted in the proper format. Once the Confirm Message is submitted, SWIFT Messaging performs syntax validation and various authentication and security procedures (~, SWIFT Messaging 2 SWIFT supports both existing MT message standards and newer XML-based MX standards, which are applied according to agreed rules within a closed community. SWIFT registers its standards with the International Organization for Standardization ("ISO") and takes a leading role in the financial industry to maintain and update its standards on a regular basis. The standards are copyrighted by SWIFT and are freely licensed so that they may be used for messaging anywhere in the world (i.e., not only in the context of SWIFT Messaging). Currently, SWIFT offers a trade confirmation message under the ISO 15022 standard through its SWIFTNet FIN messaging services. This message type is known as the MT 515 (Client confirmation of purchase or sale). In the future, SWIFT intends to offer trade confirmation messages under the newer ISO 20022 standard, which utilizes XML-based MX standards, through its SWIFTNet
InterAct messaging service. The ISO 20022 standard incorporates the same information as ISO 15022 but allows for the leveraging of more recent technology architecture. XML is the current syntax of choice for fmancial services message formats. 4 A User may also manually enter trade information to the interface device, but this happens rarely (primarily as a back-up to the automated process described above).

determines that the stated recipient is a User of SWIFT) and accepts validated ConfIrm Messages. SWIFT then delivers the accepted ConfIrm Message to the recipient User's queueS and provides to the sending User an electronic acknowledgment message that serves as proof that SWIFT has accepted the ConfIrm Message for delivery to the recipient User's queue. The recipient User empties its queue using its secure interface, which in turn is typically linked to its internal information technology systems. SWIFT's rules provide that (i) the recipient User's interface automatically sends acknowledgement of receipt of the ConfIrm Message and (ii) unless a "negative" acknowledgement is sent, the recipient User's acknowledgement means the ConfIrm Message was successfully delivered to the recipient User. SWIFT records the recipient User's acknowledgement in the message delivery history and the sending User can ascertain from this history that delivery to the recipient User has occurred. Historically, SWIFT has demonstrated the reliability of its network and messaging service by effectuating the exchange of up to 18.36 million messages per day across a wide range of business areas within the banking and securities industries. While SWIFT cannot assure what a particular User receiving a ConfIrm Message will do with it upon delivery, Users have agreed to abide by SWIFT rules pertaining to SWIFT Messaging, which (i) require Users to take steps to receive all messages queued to them during local business hours, (ii) prohibit Users receiving a SWIFT message from rejecting or ignoring the message and (iii) require a User to process a received SWIFT message or promptly revert to the sender. SWIFT's long and extensive experience with SWIFT Messaging has given no indication that receiving and processing messages in the ordinary course of business presents Users with any significant difficulties or operational challenges.6 Typically, the recipient User's in-house applications will be programmed to parse the information in the ConfIrm Message and transfer such information as appropriate to the recipient's in-house systems. The various types of information included within a Confirm Message will generally be conveyed through dedicated fIelds containing machine-readable alphanumeric codes, based on established protocols, to condense and organize that information in accordance with the accepted format for a ConfIrm Message. The User's software systems are typically programmed to parse the codes contained in these fIelds, translate them into a format acceptable for the User's in-house systems, and transfer the formatted information to the appropriate internal destination. Under the current structure of the MT515 message format, however, there is no dedicated field for certain information required by Rule 1Ob-l O. In addition, SWIFT is not able to unilaterally change the MT515 message format, as used on SWIFT, to add dedicated SWIFT Messaging operates in store-and-forward mode,
meaning that SWIFT keeps the SWIFT ConfIrm Message and delivers it as soon as the recipient is ready to receive it. SWIFT's contractual undertaking with Users essentially obligates SWIFT to deliver an accepted Confirm Message to the recipient's queue. SWIFT's rules require all Users to log in and retrieve all messages on a daily basis consistent with their recognized business days. 6

May 27,2010 fields for all the informational elements of Rule 10b-lO.? SWIFT can, however, publish instructions and guidelines that Users can follow to "structure" text in specific text fields to make it as machine-readable as information in a dedicated field. Users can then program their systems to provide and receive the relevant Rule 1Ob-l 0 information through a text field, in accordance with these instructions, as effectively as if such information were in an existing dedicated field within the MT515 message format. Because, as described above, a User's internal software applications typically transfer and translate information between the secure interface and the User's internal applications, the use of SWIFT Messaging to deliver and receive Confirm Messages facilitates straight-through processing, thereby reducing systemic and operational risk, improving settlement efficiency and minimizing operational costs. SWIFT has a number of safeguards in place to minimize the risk of system failures that would interfere with the prompt delivery of Confirm Messages or other transfers of data over the SWIFT network. In particular, SWIFT regularly tests SWIFT Messaging and the network over which it runs to ensure that they have sufficient capacity and response times to handle the volume of messages anticipated to be generated by Users of SWIFT Messaging and to mitigate the risks of any system failures. SWIFT also has back-up facilities and disaster recovery protocols to ensure continuity of service if its primary facilities become inoperable. Moreover, SWIFT Messaging operates on both a private network and a secure Internet protocol that offers high availability rates and eliminates single points of failure. SWIFT takes steps to ensure that Users adequately address and protect system access. SWIFT User guidance and documentation require customers to physically and systemically protect their SWIFT connection infrastructure against any unauthorized use of SWIFT services and products. Users must also protect against any breach or attempted breach of security that can affect the integrity or reliability of the SWIFT services and products. All Users appoint two responsible staff to act as SWIFT Security Officers. These officers have authority to assign and change access and system administration rights to others, and their actions are auditable.
III. Need and Rationale for Proposed Relief.
Many Users of SWIFT are U.S.-registered broker-dealers ("Broker Users") who currently use SWIFT Messaging to communicate a range of information with other Users (particularly non-U.S. Users, due to the widespread adoption of SWIFT Messaging and standards As Registration Authority to the ISO, SWIFT may request a permanent revision ofthe MT515 standard to include dedicated fields for all relevant Rule 10b-IO information (and assuming such revision is properly formatted and does not duplicate other revisions, this request is likely to be approved). In order to use the new message format on the SWIFT network, however, the revision must first be proposed to SWIFT's Maintenance Working Group. If approved by that Group, the revision must then be put to a vote of representatives of SWIFT's member nations (of which there are, currently, 209). 7

throughout the global financial services industry). SWIFT requests the staffs advice that these Broker Users may satisfy their obligations under Rule 10b-lO by sending a Confirm Message utilizing SWIFT Messaging to an institutional customer who is also a User (a "Customer User"). The proposed relief would have a number of important benefits for both Broker Users and Customer Users, while satisfying the objectives of Rule 10b-lO. For example, the relief would make it clear that Broker Users are permitted to transmit confirmations electronically using SWIFT Messaging for a variety oftypes of securities for which there is not presently an accepted method for electronic delivery.8 This would reduce the use of paper trade confirmations, thereby substantially decreasing costs for Broker Users and Customer Users alike. Reducing the use of paper confirmations also would better enable Users to electronically archive transaction data and regulators to audit and examine these transactions. The relief also would have benefits even with respect to transactions in those types of securities where electronic methods for delivery of confirmations are already in use. By making it clear that Broker Users and Customer Users are permitted to use their existing connections to SWIFT to send and receive Rule 10b-lO confirmations, the relief will eliminate duplicate systems and conserve resources that otherwise must be expended to maintain multiple communications linkages, thereby improving the efficiency and reliability of confirmation delivery and receipt processes. The standardized format of SWIFT's Confirm Messages also reduces trade reconciliation errors and operational risks and increases the speed at which trades may be processed and settled. In addition, because their systems link directly to a secure interface, Users can program their systems to parse the information contained in the Confirm Message, transfer that information to their own systems, and view, print, download and retain copies of a Confirm Message sent or received using SWIFT Messaging in compliance with their own regulatory requirements and in accordance with their own internal policies and procedures.9 To the extent that the Confirm Message format does not have a dedicated field for certain information required by Rule 10b-lO, SWIFT can issue instructions by which Users may include such information in specific text fields in the form of "structured" text that is machine readable. When Users follow these instructions, Rule 1Ob-l 0 information that is delivered or received in these text fields can We understand that a substantial number of transactions in the following types of securities are now typically confIrmed via paper-based methods: (a) non-depository eligible equity securities, including ordinary shares, preferred shares, convertible shares, preferred convertible shares, preference convertible shares and units (~, trusts and mutual funds); (b) debt instruments, including bonds, convertible
bonds, bonds with warrants attached, medium-term notes and money market instruments; and (c) options, including puts and calls. SWIFT also provides a service whereby its Users may retrieve messages within 124 days following transmission. Users are advised in the SWIFT User Handbook, which is updated annually, ofthis limitation on the retrieval services offered by SWIFT. Users are responsible for complying with any regulatory recordkeeping requirements applicable to them as well as their internal policies and procedures regarding document retention. 9

be parsed and translated by the User's own systems to the same extent as information in a dedicated field. We also note that NBB's oversight of SWIFT, and the high standards at which SWIFT maintains its services, as described above, provide additional assurances that use of SWIFT Messaging to deliver Confirm Messages will provide a safe, reliable and effective mechanism for Broker Users to transmit the information and disclosures required by Rule 10b-10. Finally, we note that the Commission staff has previously provided no-action relief permitting broker-dealers to rely on certain electronic delivery systems to comply with their confirmation obligations under Rule 1Ob-1 O. 1 0
IV. Conditions for Proposed Relief.
A Broker User's use of SWIFT's Confirm Messages to satisfy its Rule 1Ob-1 0 obligations would be subject to the following conditions:
(a) The Customer User may not be a natural person.
(b) The Customer User will be obligated under SWIFT's rules to log on to SWIFT on each of the Customer User's regular business days and retrieve all SWIFT messages, including Confirm Messages, stored in the Customer User's queue. (c) The Confirm Message will contain all the information required by Rule 1Ob-l 0 in a machine-readable format. I I As noted above, to the extent that the Confirm Message does not have a dedicated field for any information required by Rule 1Ob-1 0, SWIFT must have published instructions for its Users on how to create and read "structured text" within specific text fields in order to convey such Rule 1Ob-1 0 information in a machine-readable format. 12 10 See, Omgeo LLC (pub. avail. Dec. 14,2006); Thomson Financial Services, Inc. (pub. avail. Oct. 8, 1993). See also SS&C Technologies, Inc. (pub. avail. Aug. 13,2008); SunGard Institutional Brokerage, Inc. (pub. avail. July 3, 2007); TradeWeb LLC (pub. avail. July 22, 2003); MBS Clearing Corp. (pub. avail. June 27, 1997); Pacific Clearing Corp. (pub. avail. Apr. 11, 1981); The Depository Trust Company (pub. avail. Nov. 29, 1974) (and supplemented by letters pub. avail, Feb. 28 1983 and Apr. 17, 2001). 11 Responsibility for compliance with Rule 1Ob-l 0 remains with each broker-dealer using SWIFT Messaging. Each such broker-dealer must ensure that its Confirm Messages include all information required by Rule 10b-l0. 12 SWIFT will notify Users of these instructions for creating structured text through a broadcast message to all Users, and through a Message Usage Guideline document on SWIFT's website (in an area regarding messaging standards). SWIFT will also endeavor to include these instructions in the 2010 SWIFT User Handbook. Any subsequent modifications to the message standard or instructions will also be notified to Users through similar means.

May 27,2010
(d) The Broker User may utilize additional text fields to provide any additional information not required by Rule 1Ob-1 0 that the Broker User wishes to provide to Customer Users. (e) The Broker User will include a statement in the Confirm Message instructing the Customer User to contact the Broker User, and not SWIFT, with any questions. SWIFT will not participate in such post-transaction communications, although the Broker User and Customer User may elect to communicate through messaging services provided by SWIFT. (f) The Broker User must have the ability, through its system interfaces with SWIFT Messaging, to view, print or download a copy of each Confirm Message sent through SWIFT. The Broker User also must have reasonable grounds to believe that the Customer User has the ability to view, print or download a copy of each such Confirm Message sent by the Broker User to it, and the Broker User will retain and maintain records of all such Confirm Messages for the periods and in the manner required by Rules 17a-3 and 17a-4. (g) The Broker User may rely on a Confirm Message to satisfy its Rule 10b-10 obligations only if such Confirm Message is sent to the person to whom the Broker User is required to direct the confirmation under Rule 1Ob-1 O. Where the person to whom the Broker User is obligated to send a confirmation under Rule 10b-10 is not a User, the Broker User will retain the responsibility to send Rule 10b-10 compliant confirmations to that person through means other than SWIFT. (h) The Broker User will obtain the prior written, informed consent of the Customer User (which may be electronic) to the receipt of trade confirmations electronically using SWIFT's Confirm Messages. If the Customer User revokes this consent, then the Broker User will send any future Rule 1Ob-1 0 confirmations to that Customer User through means other than SWIFT. (i) Upon the specific request of the Customer User, the Broker User will provide the Customer User with a paper copy of any trade confirmation sent by the Broker User to the Customer User using SWIFT's Confirm Messages during the two years prior to the Customer User's request.
v. Analysis of Proposed Relief.
We believe that the Commission's electronic media guidance should permit a Broker User to rely on a Confirm Message sent through SWIFT in accordance with the

conditions set forth in Part IV above to satisfy its Rule 1Ob-l a obligations. 13 In that guidance, the Commission set forth three principles for determining whether a broker-dealer may use electronic media to satisfy its delivery obligations, including its obligations under Rule 10b-lO:
(a) the electronic communication should provide timely and adequate notification that the information is available electronically; 14 (b) customers who are provided information through electronic delivery should have access to that information comparable to the access that would be provided if the information were delivered in paper form; 15 and (c) the broker-dealer must have reason to believe that the electronically delivered information will result in satisfaction of the · . 16 re 1 d 1 evant e Ivery reqUIrement. We are of the view that a Broker User that sends a Confirm Message utilizing SWIFT Messaging to a Customer User in accordance with the conditions set forth in Part IV above will comply with the Commission's electronic media guidance for the following reasons:

• Notice. The Confirm Message will provide timely and adequate notification that the
  information is available electronically because each User is required by SWIFT's rules to log on to SWIFT on each of the User's regular business days and retrieve all SWIFT messages, including Confirm Messages, stored in the User's queue. 17

• Access. Customer Users will have access to information made available through
  Confirm Messages comparable to the access that would have been provided if the trade confirmation were delivered in paper form because Confirm Messages will contain all information required by Rule 10b-lO. Also, each Broker User relying on the relief must have reasonable grounds to believe that any Customer User to which it sends a Confirm Message through SWIFT has the ability to view, print or download a copy of the Confirm Message. Finally, upon the specific request of the Customer User, the Broker User will provide the Customer User with a paper copy of any trade confirmation sent by the Broker User to the Customer User using SWIFT's Confirm Messages during the two years prior to the Customer User's request. 13 See Release No. 33-7233 (May 9, 1996),61 Fed. Reg. 24644 (May 15, 1996) (the "1996 Release"); see also Release No. 33-7288 (October 6, 1995), 60 Fed. Reg. 53458 (October 13, 1995) and Release No. 33-7856 (Apr. 28, 2000), 65 Fed. Reg. 25843 (May 4, 2000). 14 1996 Release at 24646. 15 rd. at 24646-47. 16 rd. at 24647. 17 Cf. rd. at 24560 (noting that information delivered by a company to its employees using e-mail satisfies delivery requirements under the Exchange Act because employees ordinarily are expected to log-on to e-mail routinely).

• Evidence to Show Delivery. Broker Users will have reason to believe that the
  information delivered through Confirm Messages will result in satisfaction of Rule 1Ob-1 0 because they will obtain the prior written, informed consent of each Customer User (which may be electronic) to the receipt of trade confirmations electronically using SWIFT's Confirm Messages. 18 Additionally, as noted in Part II above, when SWIFT receives a valid Confirm Message it is obligated to deliver the Confirm Message to the recipient's queue and, ultimately, the Broker User is able to confirm delivery of the Confirm Message to the recipient User.
  VI. Conclusion.
  Based on the foregoing, SWIFT respectfully requests the Commission staff's advice that it would not recommend any enforcement action to the Commission if Broker Users rely on Confirm Messages sent using SWIFT Messaging in accordance with the conditions set forth in Part IV above to satisfy their obligations under Rule 1Ob-1 0 of the Exchange Act.

---

If you have any questions regarding this letter, please do not hesitate to contact the undersigned at 212455 1902, our General Counsel, Blanche Petre, at 011 322655 3150, or David Aman of Cleary Gottlieb Steen & Hamilton LLP, outside counsel to SWIFT in this matter, at 2122252262. Sincerely, Charles Llewellyn Regional Legal Counsel - Americas SWIFT cc: Daniel Fisher, Esq., Branch Chief Such consent will also ensure that the Customer User is willing to accept delivery of personal financial information through electronic media and has actual notice that the personal financial information will be delivered electronically. Also, as described more fully in Part II above, SWIFT Messaging operates on both a private network and a secure Internet protocol and SWIFT takes steps to ensure that Users adequately address and protect system access. These measures help to ensure the integrity, confidentially and security of personal financial information transmitted using SWIFT Messaging. See 1996 Release at 24647 (describing requirements for transmitting personal financial information using electronic media). 18