The full text on this page is automatically extracted from the file linked above and may contain errors and inconsistencies.
FEDERAL RESERVE BANK OF NEW YORK [ Circular No. 10759 January 9, 1995 "1 FE D W IR E FU N D S T R A N SF E R C H A N G E S — Expanded Fedwire Funds Transfer Format — Delay in Implementation of Expanded Operating Hours To All Depository Institutions in the Second Federal Reserve District, and Others Concerned: The Board of Governors of the Federal Reserve System has announced its approval of an expanded Fedwire funds transfer format, which includes an implementation schedule for Fedwire participants to convert to the new format. In addition, the Board of Governors has announced a delay in the implementation of its previously announced expanded Fedwire on-line funds transfer operating hours in order to provide banks that intend to participate in those expanded hours an opportunity to complete their conversion to the new format. In conjunction with these actions, the Board issued the following statements: Expanded Fedwire Funds Transfer Format The Board has announced plans to expand the Fedwire funds transfer format and to adopt a more comprehensive set of data elements. The new format will be implemented fully by year-end 1997. An expanded Fedwire funds transfer format will improve efficiency in the payments mechanism by reducing the need for manual intervention when processing and posting transfers. Further, the new format will eliminate the need to truncate payment-related information when forwarding payment orders through Fedwire that were received via other large-value transfer systems, such as the Clearing House Interbank Payments System (CHIPS) and the Society for Worldwide Interbank Financial Telecommunication (S.W.I.F.T.) system. The increased size and more comprehensive set of data elements will permit the inclusion of the name and address of the originator and beneficiary of a transfer, which is required under regulations that have been adopted by the Department of the Treasury. Delay in Expansion of Fedwire Funds Transfer Operating Hours The Board has announced a delay in the implementation of the expanded Fedwire on-line funds transfer operating hours until fourth quarter 1997. A specific implementation date will be announced one year in advance of the effective date. In February 1994, the Board approved the expansion of the Fedwire on-line funds transfer service operating hours to 18 hours a day, from 12:30 a.m. to 6:30 p.m. Eastern Time (ET), beginning in early 1997. Currently, the Fedwire funds transfer service operates 10 hours a day, from 8:30 a.m. ET to 6:30 p.m. ET. Expansion of the Fedwire on-line funds transfer service operating hours to 18 hours a day could be a useful component of private-sector initiatives to reduce settlement risk in the foreign exchange markets and will eliminate an operational barrier to potentially important innovation in privatelyprovided payment and settlement services. The Board has delayed the implementation of the expanded Fedwire funds transfer operating hours to provide banks that intend to participate during the expanded hours an opportunity to first complete their conversion to the new Fedwire format. The Board believes a modest delay in the implementation of the earlier Fedwire opening time will be sufficient to address industry concerns regarding the interdependencies between these two Fedwire initiatives, while not deferring for a significant period of time the potential changes in payment and settlement practices that can contribute to reductions in Herstatt risk. Printed on the following pages are the texts of the Board’s notices in these matters, which have been submitted for publication in the Federal Register. Questions may be directed to Andrew Heikaus, Assistant Vice President, Electronic Payments Function (Tel. No. 212-720-5561). W illiam J. McD onough , President. 2 FEDERAL RESERVE SYSTEM [Docket No. R-0817] Federal Reserve Bank Services AGENCY: Board of Governors of the Federal Reserve System. ACTION: Notice of service enhancement. SUMMARY: The Board has approved a proposal to expand the Fedwire funds transfer format and adopt a more comprehensive set of data elements. The new format will be implemented fully by yearend 1997. An expanded Fedwire funds transfer format will improve efficiency in the payments mechanism by reducing the need for manual intervention when processing and posting transfers. Further, the new format will eliminate the need to truncate payment-related information when forwarding payment orders through Fedwire that were received via other large-value transfer systems, such as the Clearing House Interbank Payments System (CHIPS) and the Society for Worldwide Interbank Financial Telecommunication (S.W.I.F.T.) system. The increased size and more comprehensive set of data elements associated with the new format will permit the inclusion of the name and address of the originator and beneficiaiy of a transfer, which is required under regulations adopted by Treasury. DATES: Institutions can implement the capability to receive Fedwire transfers in the new format beginning July 1, 1996. Institutions can implement the capability to send Fedwire transfers in the new format beginning June 23, 1997, at which time all institutions must have the capability to receive newformat messages. The conversion to the new Fedwire format must be completed by December 29, 1997. FOR FURTHER INFORMATION CONTACT: Louise L. Roseman, Associate Director (202/4522789), Gayle Brett, Manager (202/452-2934), or Sandra Scales, Financial Services Analyst (202/4522728), Division of Reserve Bank Operations and Payment Systems. For the hearing impaired only: Telecommunications Device for the Deaf, Dorothea Thompson (202/452-3544). SUPPLEMENTARY INFORMATION: The majority of large-dollar electronic funds transfers between financial institutions in the United States flow over the Federal Reserve Banks’ Fedwire funds transfer system and the Clearing House Interbank Payments System (CHIPS), which is operated by the New York Clearing House. In 1993, the daily average volume of Fedwire payments was 277,000 with a value of $824 billion and the daily average volume of CHIPS payments was 168,000 with a value of $1,055 billion. A significant number of these transfers, particularly CHIPS transfers, are based on payment instructions received over a message switching system operated by the Society for Worldwide Interbank Financial Telecommunication (S.W.I.F.T.). From time to time, the format used to transmit payment orders on Fedwire has been modified to address the industry’s need for standards that facilitate end-to-end computer processing.1 In November 1992, the American Bankers Association (ABA) Funds Transfer Task Force, under the 'The structured Fedwire format, announced in 1986 (51 FR 43086, November 28, 1986), provided a set of field tags to convey third-party transfer information in a specific order within what was formerly the ffee-text section of the message. 2 auspices of the ABA Wholesale Operations Committee, recommended that the Federal Reserve Banks adopt a more comprehensive set of data elements for wholesale electronic funds transfers, and proposed a new Fedwire format. Federal Reserve staff conducted a detailed business analysis of the format proposed by the ABA and evaluated requests from the Departments of Justice and Treasury to modify the existing format to include complete transfer party information in the payment order to assist in anti-money laundering efforts. In December 1993, the Board issued for public comment a proposal to expand the Fedwire funds format and to adopt a more comprehensive set of data elements by late 1996 (58 FR 33366, December 1, 1993). The proposed format was substantially similar to the CHIPS-like format proposed by the ABA, but with minor modifications to accommodate certain Fedwire business and technical specifications. The Board requested comment on its anticipated effects on and benefits to depository institutions. Summary of Comments Comments were received from sixty-seven organizations, including commercial banks, clearing houses, credit unions, vendors, and trade associations. Most depository institution commenters use a computer-interface connection to the Federal Reserve for Fedwire transfers. Most of the commenters that use a computer-interface connection also use vendor-supplied funds transfer software. The number of commenters by type of organization is identified in the following table: Commenter Tvoe Count Clearing House Commercial Bank/Bank Holding Company2 Corporate Credit Union Corporation Credit Union Federal Home Loan Bank Federal Reserve Bank Savings Bank Trade Association Vendor Total 2 46 2 1 2 1 4 1 4 _4 67 The majority of commenters generally were supportive of the proposal to expand the Fedwire funds transfer format. The forty-eight commenters supporting the proposal included all the trade associations, the majority of the largest depository institutions, and the one corporation that commented. Many of these commenters noted the opportunities afforded by the new format to automate more fully institutions’ backroom processing and to improve compatibility with the CHIPS payment system. These commenters also expressed an awareness that this conversion would be very costly to the industry because of the required changes in backroom and customer delivery systems. Twelve commenters, including three vendors, did not state whether they supported the proposal. Many of these commenters noted that the format was forward-looking and an important 2Six separate but identical responses received from affiliated institutions were counted as one response to provide a consistent treatment with other single responses received from groups of affiliated institutions. 3 enhancement to the Fedwire service, but also the most difficult and costly change ever made to Fedwire. Six commenters strongly opposed the proposal to expand the format. These commenters indicated that conversion of internal and customer systems to accommodate the expanded format would be very costly, and that those costs would exceed any potential benefits. These commenters also noted that the regulatory pressure to carry more complete transfer party information was a main driver in the need to adopt an expanded format. These commenters did not agree with law enforcement’s perceived need for this transfer party information to travel with the transfer as such information should be readily available at the depository institutions. One commenter suggested that the Federal Reserve Banks should find a less complex way to expand the format to meet the requirements of the Treasury’s proposed regulation that would require financial institutions to include certain information in payment orders they send (58 FR 46021, August 31, 1993) (the Travel Rule). The Board believes there are significant benefits to the industry associated with an expansion of the Fedwire funds transfer format. The Board also recognizes that the implementation costs to both the Federal Reserve Banks and industry will be substantial. In the longer term, operational gains achieved by automating more fully both the mapping between funds transfer systems and the institutions’ backroom processing should help offset the implementation costs the industry will incur. The Board has adopted the expanded Fedwire funds transfer format, which will be implemented fully by year-end 1997. A detailed description of the expanded format and examples of usage for business and law enforcement purposes are included later in this notice. A list of field tags and a glossary of terms and field tag definitions are attached to this notice. Proposed Implementation Approaches. The Board requested comment on the viability of three different implementation cutover plans and the anticipated effects on and benefits to depository institutions of each approach. The Board has considered the advantages and disadvantages that commenters attributed to each of the implementation alternatives. In defining an implementation strategy, the Board considered the risk of disruption to the payments system, operational burden, and business needs. The alternatives that were considered included an institution-by-institution full function, staggered-date conversion, a nationwide same-day cutover, and a receive-first phased conversion. A brief description of each alternative, as proposed, is provided below, followed by the comment summary. Institution-by-Institution Staggered-date Conversion —Under this approach, each institution would select a date over the course of twelve months on which to convert both its send and receive functions to accommodate the new format. The Fedwire software would accept messages in either format and map between formats. All participants would be required to complete conversion to the new format by a designated date, after which time the current format would no longer be supported. Participants would implement the new format on a staggered schedule. As a result, a participant could send a message in a format that the receiver cannot process. In this case, the Fedwire application would convert the message to a format that the receiver can process. For example, if the receiver was able to accept the new format, then messages originated in the old format would be mapped into the new format. The Fedwire software would convert the field tags and identifier codes to the equivalent fields in the new format. If the receiver was still processing the old format, then messages received in the new format would be reduced to the old format; however, critical payment-related information might be truncated. That is, if the sending bank included more 4 information in a field than the equivalent field in the old format could accept, the extra characters would be omitted from the message delivered to the receiver. Truncation could occur because the new format allows a sender to include up to three times as much payment-related information as the current format. In some cases, data truncation could be very extensive. Nationwide Same-day Cutover ~ Under this strategy, all participants would cut over on the same day and would be required to both send and receive transfers in the new format. There could be a substantial disruption to the payments system if one or more large participants were unable to process the new format or were to experience some other implementation-related problem that denied the participants access to the Fedwire funds transfer service. Complete and comprehensive testing on the part of every on-line institution, both internally, with other participants, and with the Federal Reserve Banks, would be required for a conversion of this magnitude to be successful. Receive-first Phased Conversion —This alternative entails a two-stage implementation, wherein participants would begin receiving the new format before they would begin sending the new format. Messages sent in the current format would be converted to the new format by the Federal Reserve Banks’ Fedwire application, then delivered. As originally proposed, each stage would last four to six months. During phase one, participants would convert from receiving the old format to receiving the new format. In this phase, the Fedwire application would accept only messages sent in the old format but would deliver messages in the format the receiver was capable of processing. That is, until a receiver is capable of receiving the new format, all messages would be delivered to the receiver in the old format. Once the receiver is able to receive the new format, the Fedwire application would convert and deliver messages to that receiver in the new format. The Fedwire funds software would convert the message by mapping the information in the old format to the equivalent fields in the new format. As the field lengths in the new format are equal to or larger than the equivalent field in the old format, all transfer information would be carried forward. The "new format" message will contain only the field tags necessary to carry forward all the information in the "old format" message. The converted message may be somewhat longer than the original message because information commingled in the third-party portion of the old format would be allocated to specific field in the new format and every field would include a tag. At the end of phase one, all participants would be required to have the ability to receive transfers in the new format. During phase two, participants would convert from sending transfers in the old format to sending the new format. In this phase, the Fedwire software would continue to accept messages sent in the old format, but also would accept messages sent in the new format. Until a sender begins sending the new format, the Fedwire application would continue to accept the sender’s messages and convert them to the new format for delivery to the receiver. All messages would be delivered to the receiver in the new format. At the end of phase two, all participants would have the ability both to send and receive the new format. The old format would no longer be supported. Eight commenters, including a few large regional banks and a trade association representing community banks, indicated that the institution-by-institution full function conversion would be the most beneficial. Commenters favoring this alternative noted that participants would implement the new format on a staggered schedule, reducing the likelihood of a major payment system disruption because few banks would go through the transition on any given day. Commenters indicated that conversion costs would be minimized because institutions could convert both the send and receive functions at a convenient time. Commenters also indicated that fall back to previous software would be easier to achieve if a conversion failed. In addition, the staggered-date approach 5 would reduce the interdependency among depository institutions—the failure of any one depository institution’s conversion would not delay the subsequent conversion of another depository institution. Eight commenters, predominately money center banks and one trade association, strongly opposed an institution-by-institution full function conversion, expressing concerns about the potential for data truncation and the possibility that the transition period could extend well beyond the proposed sunset date. These commenters emphasized that adoption of this alternative would reduce the likelihood of a major payment system disruption, but indicated that business risk might increase substantially due to the potential truncation of important data. The data truncation necessary to support the staggered-date conversion schedule also would delay a participant’s ability to take full advantage of the benefits of the new format until all participants have converted. Twelve commenters, predominantly money center banks, were very supportive of a same-day implementation, anticipating that this alternative would reduce significantly participants’ costs by eliminating the need to support two formats simultaneously. This plan would allow all participants simultaneously to take advantage of the benefits of an expanded format, including the ability to automate more fully incoming transfer processing and message mapping between transfer systems. Many commenters favoring a same-day implementation noted that CHIPS had successfully implemented a new format using a same-day implementation plan. Commenters favoring a same-day implementation acknowledged that there is significant risk associated with this implementation plan. These commenters indicated that the risk of payment system disruption could be diminished substantially by complete and comprehensive testing on the part of every on-line institution, both internally and with the Federal Reserve Banks. Some commenters supporting a same-day cutover said that the risk that one or more large institutions may not be able to complete the conversion could be controlled adequately through thorough testing. Fourteen commenters strongly opposed a same-day cutover implementation plan, due to the potential risks to the payments system. Under a same-day cutover, there could be a substantial disruption to the payments system if one or more large participants were unable to process transfers in the new format or experienced some other implementation-related problem that denied the participant(s) access to the Fedwire funds transfer service. One commenter suggested that the risk of a payment system disruption could be eliminated if this alternative were modified to incorporate elements of the other two alternatives, that is, the Federal Reserve Banks should accept both formats, map between formats, and deliver the old format to any participant that failed to convert on the designated date. Thirty-eight commenters, predominately large regional banks and most vendors and trade associations, indicated strong support for the two-phase approach. Commenters favoring the receive-first phased approach emphasized that this alternative limits the risk that the overall payments system would experience a major disruption because relatively few banks would go through the conversion on a given day. Some commenters favoring a two-phase implementation recognized that costs may be somewhat higher because separate testing would be required for the send and receive phases; however, commenters also indicated that separating the conversion along functional lines helps minimize the risk of a complete disruption of service for both the individual participant and the payments system. One commenter opposed a two-phase implementation, indicating that this solution would likely increase automation costs because of the need to support two formats for a period of time. This commenter was particularly concerned that a participant’s incoming and outgoing messages would be stored in different formats, thereby increasing storage costs, complicating money laundering monitoring, and creating confusion in conversations between banks about a particular transfer. This commenter also was concerned that it would be difficult for the Federal Reserve Banks to manage and coordinate approximately 300 computer-interface participant conversions in two phases lasting 4-6 6 months each. The Board believes that the institution-by-institution full function conversion is the least desirable approach from a business perspective because the process of mapping transfer messages from the new format to the old format may result in truncation of critical payment-related information. A sender using the new format would need to be aware that a receiver may not use the new format. It is unlikely that most participants would choose to track whether the intended receiver of each transfer was using the new format, so a sender would need to limit the size of all messages or risk truncation of critical payment data prior to delivery to "old format" participants. There would be an increased business risk for all receivers that use the old format because any messages sent in the new format could exceed field length guidelines, perhaps losing critical payment information in the truncation process. The receiver that converts late in the process has an increased risk of misapplying payments and incurring posting delays because most of the transfers it receives would have been originated under the new format and information required to fully identify the beneficiary or describe the terms of payment may have been truncated prior to delivery. The Board believes that the potential for truncation of critical payment information represents a significant business risk that precludes the adoption of this implementation plan. The Board acknowledges that the same-day cutover implementation plan has certain advantages for a select subset of institutions. This approach also poses the most risk of a serious disruption to the Fedwire system and to the financial markets more generally. A same-day cutover requires every depository institution that participates on Fedwire using an on-line connection to bring new or substantially modified software into the production environment for the first time on the same date. The Board agrees that complete and comprehensive testing is essential to the success of any implementation plan, but also recognizes that testing cannot eliminate fully the risk that one or more participants may fail to convert successfully on the designated cut-over date. Due to the magnitude of the software changes and the large population of participants, it would not be feasible to fall back to the previous software if problems during cutover were encountered. It would be impossible to coordinate the timely de-installation and re-installation of software at more than 8,000 institutions and related procedural changes for more than 11,000 institutions. Even if only a small number of depository institutions could not convert successfully and these institutions were able to fall back to previous software, there would still be the potential for data truncation as described in the institution-by-institution alternative if the Federal Reserve Banks attempted to map messages from the new to the old format. Due to the difficulties associated with recovering or otherwise supporting a large number of participants in the event of a failed conversion, the Board has concluded that a same-day cutover is not feasible on a large-scale basis. The Board believes the most prudent approach is a two-staged implementation wherein participants begin receiving Fedwire transfers in the new format before they begin sending new-format transfers. The Board believes that the receive-first phased implementation plan minimizes the risks to the payment system and eliminates the need for truncating payment-related information during the conversion period. The Board recognizes that depository institutions will incur some incremental operational burdens and cost to support two formats for a period of time. The commenters indicated that most computer-interface banks are using software that separates transaction processing and record storage along the send and receive functional lines; therefore, there should not be a substantial increase in cost to use a different format for each function, that is, to send in one format and receive in a different format. Further, commenters note that the cost increase associated with supporting two formats for a period of time would be offset somewhat by the improved training and testing opportunities associated with receiving the new format in advance of originating it. Nonetheless, the Board recognizes that there will be inefficiencies and potential for confusion associated with processing and supporting two formats for a period of time. In an effort to minimize costs to the 7 industry, the Federal Reserve Banks plan to make the send and receive portions of the Fedwire software available at the same time in the test environment for testing and software certification purposes. This will allow the majority of participants to follow a conversion plan that minimizes the duplication of testing and implementation tasks. Implementation Strategy. The Board has adopted an implementation strategy that entails a phased conversion of the receive and send functions. During the first phase of the conversion, when depository institutions implement the capability to receive transfers in the new format, the Federal Reserve Banks will maintain information regarding the format that each depository institution is capable of receiving. Based on this information, the Fedwire software will convert messages to the new format for delivery to institutions capable of receiving that format. On the first day of the send conversion period, all participants must be capable of receiving the new format and the Federal Reserve Banks will no longer deliver messages in the old format. In those cases where a depository institution fails to convert the receive function by the beginning of the send period, the Federal Reserve Bank would continue to post transfers to the depository institution’s account and deliver advices of these transfers in the new format to the depository institution using an alternative method, such as magnetic tape. The Board recognizes that some depository institutions have a very strong desire to convert both the send and receive function on a same-day basis. The Board desires to balance the business needs of these participants against the concern that the failure of one or more large participants may disrupt the payment system. Therefore, the Board is adopting a modification to the two-staged, receive-first alternative that will accommodate full-function conversion of a limited number of depository institutions on the first day of the send period, providing that these institutions meet stringent guidelines for testing and recoverability. The ideal candidate for a same-day conversion will have exhibited previous success in completing a major format conversion for a funds transfer application on a same-day basis. The Federal Reserve Banks will work closely with depository institutions that desire to convert on a same-day basis to determine whether the testing and recoverability guidelines can be satisfied. A depository institution that fails to convert on a same-day basis, and is not successful in falling back to software capable of receiving messages delivered in the new format, may experience a severe disruption of its ability to receive advices for incoming transfers as some participants will have begun sending in the new format on this date. In understanding the risks associated with choosing a same-day cutover, a depository institution should recognize that timeliness of delivery of advices by its Federal Reserve Bank may be affected, which could affect the institution’s ability to post transfers to its customers’ accounts on a timely basis. Depository institutions are required to implement the capability to receive transfers in the new format by the first day of the send period. In the unlikely event that some depository institutions fail to meet this requirement and will require delivery of messages via an alternative method, the Board may impose a charge for such deliveries. A more complete discussion of the length and timing of the phases of the implementation plan is provided in the description of the schedule. Schedule. Implementing the format will require extensive application development work on the part of the Federal Reserve Banks. Also, depository institutions using in-house or vendor-supplied funds transfer systems will need to make significant automation changes to send and receive the new format. The Board recognizes that many large depository institutions today use vendor-provided or in-house developed software to participate in CHIPS and S.W.I.F.T. Because these institutions are familiar with formats similar to the expanded format adopted for Fedwire and i 8 have already adopted interfaces with internal systems to accommodate these similar formats, it is assumed that the conversion effort for these institutions will be somewhat reduced. The Federal Reserve Banks provide software to approximately 7,900 depository institutions that access Fedwire through Fedline®.3 Fedline® institutions will be somewhat less affected as the Fedline® software enhancements required to implement the expanded format will be provided by the Federal Reserve Banks; however, Fedline® participants will require substantial education and training to become familiar with the new format. In addition, those institutions with back-office systems that interface with Fedline® may need to modify such systems to support the new format. In its December 1993 notice, the Board proposed that the expanded format be implemented by late 1996. Commenters generally were supportive of a late 1996 implementation completion date; however, many commenters requested that the Computer Interface Protocol Specifications (CIPS) be published in mid-1994, at least 18 months in advance of conversion. Many commenters requested extension of the implementation date to late 1997. Twelve commenters were concerned that the proposed schedule was too ambitious because banks need to devote resources to support other funds-transfer-related initiatives, such as electronic tax collection and anti-money laundering rules, as well as implementation of the new Fedwire book-entry securities software and expansion of the Fedwire funds transfer operating hours. Commenters also noted that depository institution resources will be constrained by internal projects, such as mergers and/or acquisitions, product development, and application maintenance during the same period. A few commenters specifically requested that the Board delay expansion of the Fedwire funds transfer operating hours until the new format has been implemented fully. Upon careful consideration of the comments received, the Board believes that the burden of converting to an expanded format can be lessened somewhat by extending the completion date to year-end 1997. The Federal Reserve Banks plan to complete software development efforts and conduct preliminary internal testing of the revised Fedwire software by January 1996, followed by three months of testing with selected computer-interface and Fedline depository institutions. The full population of on-line depository institutions will conduct testing from April 1996 through December 1997. This should allow sufficient time for the Federal Reserve Banks to make necessary changes both to the Fedwire funds transfer system and Fedline® software, and for the industry to incorporate and fully test the software changes that must be made to the funds transfer, customer delivery, and back-office processing systems used by depository institutions. The Board understands the industry’s desire to obtain the CIPS document, which details software and technical requirements, and installation and certification testing guidelines, well in advance of the beginning of the conversion period. CIPS for the new format, which should be used by depository institutions as a basis for modifying their funds transfer software, will be published in July 1995, six to nine months in advance of when Fedwire software will be made available for testing and one year in advance of the beginning of the conversion period. As phase one of the conversion period will last one year, there should be sufficient time in the schedule to accommodate those depository institutions that require at least an 18-month lead time to incorporate the CIPS into their systems. Several commenters urged the Federal Reserve Banks to increase availability of test systems and resources, extend the testing period, and provide a dedicated test facility for vendors. The success of the CHIPS format conversion was credited largely to robust testing. The Board recognizes that a 3Fedline® is the Federal Reserve’s proprietary software package for personal computers that is used by lowto-medium volume Fedwire participants to access Federal Reserve services electronically. 9 successful and smooth transition to a new Fedwire format will require the allocation of significant testing resources because every depository institution using an electronic connection will be required to bring new or substantially modified software into the production environment. The Federal Reserve Banks plan to provide increased testing resources and business support to depository institutions and vendors during the testing and conversion period. The revised software that supports the expanded Fedwire format, including both the send and receive functions, will be made available beginning January 1996, when selected depository institutions will be requested to participate in the Federal Reserve Banks’ internal certification of the Fedwire software. Upon completion of internal certification of the software, the new Fedwire software that supports the new format will be made available for testing beginning April 1996 for on-line depository institutions with early conversion dates. The testing phase for depository institutions with computer-interface connections will encompass two steps: application software certification and implementation testing. Fedline® software will be certified by the Federal Reserve Banks prior to its distribution to depository institutions. Vendors and depository institutions that have developed in-house computer-interface funds transfer systems will be required to demonstrate that their software will accommodate the new Fedwire format. All computer-interface depository institutions will be required to successfully complete pre-production implementation tests, that is, tests that simulate a normal processing day and demonstrate that the institution can meet all of the CIPS requirements. Vendors that have completed national protocol certification will be given access to the depository institution test system. The Federal Reserve Banks will work closely with depository institutions to schedule and manage the timing of depository institution conversions. If not carefully managed, individual conversion delays could result in overall schedule delays. In late 1995, the local Federal Reserve Banks will contact depository institutions to develop a conversion schedule. It is important for each depository institution to work with its local Federal Reserve Bank to determine appropriate dates for its conversion of the receive function during phase one and the send function during phase two as only a limited number of depository institutions will be able to schedule conversions on any given date. A limited number of depository institutions that meet specific, stringent certification requirements will be permitted to schedule a same-day conversion of the send and receive functions on the first day of the send period. Phase one of the implementation, during which participants convert from receiving the current format to receiving the new format, will begin in July 1996 and end May 23, 1997. In this phase, Fedwire software will accept only the current format but will deliver in the format the receiver is capable of processing. At the end of phase one, all participants will be required to have the ability to receive the new format, except those specifically certified to convert both the send and receive functions on the first day of phase two. A stabilization period of four weeks (Saturday, May 24 through Friday, June 20, 1997) will be provided at the conclusion of phase one. If any depository institution has failed to convert the receive side during a previously scheduled date in phase one, it will be permitted to complete implementation of the receive function during the stabilization period. Phase two of the implementation, during which participants convert from sending the old format to sending the new format, will begin Monday, June 23, 1997. This date also is the designated cutover date for those depository institutions that have certified software and recovery capabilities for same-day conversion of the send and receive functions. Beginning on the first day of the send period, the Federal Reserve Banks will no longer deliver funds transfer messages to the receiver in the old format; every participant will be required to accept the new format. Until a sender begins sending the new format, Fedwire will accept the sender’s messages and convert them to the 10 new format for delivery to the receiver. Phase two will end Monday, December 29, 1997, at which time all participants will be required to both send and receive the new format. The following table summarizes the schedule for implementation of the new Fedwire funds transfer format. Task Start Date Distribute CIPS 7/95 Selected Depository Institution Participation in Testing 1/96 4/96 Full Population Depository Institution Testing —Receive & Send Functions 4/96 12/97 Phase I — Convert Receive Function 7/1/96 5/23/97 Stabilization Period 5/24/97 6/20/97 Same-day Conversions 6/23/97 6/23/97 Phase II - Convert Send Function 6/23/97 12/29/97 End Date Expanded Operating Hours. In February 1994, the Board approved expansion of the Fedwire on-line funds transfer operating hours to 18 hours per day from the current 10 hours per day, beginning in early 1997 (59 FR 8981, February 24, 1994). The opening time will be revised from the current 8:30 a.m. ET to 12:30 a.m. ET, but the closing time will remain unchanged at 6:30 p.m. ET. Over time, longer Fedwire funds transfer hours will have public policy benefits because the availability of final payment capabilities during the early morning hours can strengthen interbank settlements and contribute to reductions in Herstatt risk through innovations in payment and settlement practices. The Board has considered commenters’ requests to delay implementation of expanded funds transfer operating hours until the new format has been implemented fully. The Board recognizes that although participation is voluntary, many depository institutions believe that market forces would require their participation during the expanded funds transfer operating hours. Some commenters stated that they may need to implement software modifications to shorten back-office posting and processing cycles in order to take full advantage of the expanded funds transfer operating hours. These commenters indicated that the allocation of bank resources to implement a new format may contend directly with efforts to modify software to accommodate expanded Fedwire funds transfer operating hours. After considering these and other issues, the Board has delayed implementation of the 12:30 am ET opening time for the Fedwire funds transfer service until late 1997.4 (See notice elsewhere in today’s Federal Register.) 4An exact date for expanded funds transfer operating hours will be announced approximately one year prior to the effective date. 11 Usefulness to Law Enforcement. On August 31, 1993, the Treasury requested comment on a proposed regulation that would require financial institutions to include certain information in payment orders that they send (58 FR 46021, August 31, 1993) (the Travel Rule). Law enforcement agencies have indicated that the inclusion of complete transfer party information in the payment order will be particularly useful in tracing the proceeds of illegal activities and will assist in identifying and prosecuting persons involved in such illegal activities. Commenters generally acknowledged that the Fedwire format must be expanded to accommodate the information desired for law enforcement purposes, although many did not agree this information should be carried in the message, because the information could be obtained from the depository institutions that are parties to the transfer. Further, commenters stressed that the Travel Rule should not require complete transfer party information in Fedwire transfers until such time as the format can accommodate its inclusion. The Treasury has considered these concerns and has revised the final Travel Rule to accommodate the limitations of the current Fedwire format. In particular, the Travel Rule as adopted does not require that Fedwire transfers include the address of the transmitter until completion of the implementation of the expanded format. (See notice elsewhere in today’s Federal Register.) Description of the Expanded Fedwire Format. The expanded Fedwire format includes a comprehensive set of the elements commonly used in the origination and receipt of payment orders. It is similar to the CHIPS and S.W.I.F.T formats and provides an expanded message length and variable-length fields. The expanded format is modeled on the CHIPS format and only differs when necessary to accommodate technical processing requirements specific to Fedwire or to delete technical processing requirements specific to CHIPS. Additional fields have been defined, and the fields that carry payment details are larger than those in the current Fedwire format. The larger fields permit the inclusion of more complete information about the parties to a transfer and allow space for additional payment information. There is adequate space to provide the name, account number or other identifying number, and three lines of address information for each party to the transfer. The expanded format differs from the current Fedwire format in several significant ways: messages are not required to be fixed length but may vaiy in length; maximum message length is significantly expanded; the number and size of fields have significantly increased; and field tags (codes that identify the type of information a field may carry) are numeric rather than alpha. Numeric tags are used because they are more flexible than letter groupings and they facilitate the mapping of information between transfer systems. The format is highly structured--a field tag is used to designate the contents of every field in the message. Together, these changes provide the ability to translate fully and consistently payment order information into discrete fields, which will permit Fedwire participants to automate more fully payment order processing. The presentation of routing and transfer information in the expanded format has been reorganized to follow more closely the path of a message from sender to receiver. The expanded format presents the sending bank routing number and sending bank name before the receiving bank routing number and receiving bank name. The expanded format also reorganizes transfer party information, presenting the flow of funds and information from the perspective of the receiver. That is, the intermediary bank, beneficiary bank and beneficiary information fields precede the originator, originating bank, and instructing bank information fields.5 The expanded format’s presentation of 5The terminology used here generally conforms to the definitions in Article 4A of the Uniform Commercial Code; however, the field names in the proposed format use the term "financial institution" instead of bank. Terminology related to nonbank financial institutions conforms to the definitions in the wire transfer 12 routing and transfer party information is consistent with the presentation of similar data in the CHIPS format. Commenters generally agreed with the format as proposed; however, a few commenters suggested the format be revised. Suggested modifications included: eliminate the requirement for punctuation and disallow the dollar sign in the amount field; provide quality edits for beneficiary account number field; and activate charges tag. Commenters also requested that the new format retain the existing alpha tags; include descriptive titles with numeric tags; and include special tags for service and drawdown messages. Further, commenters identified the potential for using Fedwire to effect tax payments and Electronic Data Interchange (EDI). One commenter identified circumstances, when mapping from the old format to the new format, that the potential for truncation may exist. Some commenters indicated that punctuation and dollar sign are unnecessary in the amount field because the software depository institutions use to send and receive Fedwire funds transfer messages has the capability to display Fedwire information in a manner that is inherently more "user friendly" than the way the same information may be recorded in the Fedwire format. For example, it is not necessary for the Fedwire format to require inclusion of punctuation and the dollar sign because both the sending and receiving banks’ software can append these attributes when displaying the information on screens or reports. Further, as the CHIPS format does not include punctuation and dollar sign in the amount field, the inclusion of these characters in the Fedwire funds transfer format introduces inconsistency between the formats. Therefore, the format the Board has adopted does not accommodate punctuation or a dollar sign in the amount field. One commenter requested that Fedwire perform quality edits on certain fields to ensure the contents conform to the provisions of the Travel Rule; for example, the beneficiary field should be edited to ensure account number has been included. The Board believes it would be appropriate to edit for the inclusion of information in certain required fields; however, it would be infeasible to edit and reject messages based on the meaningfulness of the data in those fields. Specific editing criteria for field contents will be provided in the CIPS distributed in mid-1995. One commenter requested that the charges tag, which was reserved for future use, be activated now to allow a sender to instruct a receiver, when appropriate, to deduct charges and expenses from the principal amount. The commenter noted that activation of the tag would increase compatibility between payment systems because a similar field currently is provided in both the CHIPS and S.W.I.F.T. formats. The charges tag has been activated as an optional field.6 Some commenters expressed concern that the alpha tags will be replaced with numeric tags and that the numeric tags will not automatically display descriptive titles. The Board believes that, to facilitate the use of the format by depository institution staff and customers, the software resident at the sending and receiving institutions should have the capability to translate numeric tags into descriptive field tag titles on screens, advices and reports. The screens provided by the Fedline® software, as well as paper advices and reports provided by the Federal Reserve Banks, will include recordkeeping rule adopted by the Treasury and the Board. (See notice elsewhere in today’s Federal Register.) 6Article 4A-302(d) of the Uniform Commercial Code states that unless instructed by the sender, the receiving bank may not obtain payment of its charges for services and expenses in connection with the execution of the sender’s payment order by issuing a payment order in an amount equal to the amount of the sender’s order less the amount of charges, and may not instruct a subsequent receiving bank to obtain payment of its charges in the same manner. 13 descriptive field tag titles; however, these titles will not be included in the formatted messages transmitted over communication lines. One commenter noted that the proposal did not address all the different types of messages that could be sent over Fedwire and requested clarification. The Board recognizes that use of a uniform format as a basis for all types of Fedwire messages, including drawdown messages, service messages, and other non-value messages, provides a certain level of standardization essential to automating more fully back-office processing. Fedwire fimds-related messages, that is, drawdown messages, service messages, and other non-value messages, will be subject to the new format. A new field tag(s) will be defined for use with drawdown and service messages; the CIPS document will detail the specifics of formatting these types of non-value messages. A depository institution also may use the Fedwire funds transfer system to communicate a notice of nonpayment for a check that will be returned from a paying bank to a depositary bank as required under 12 CFR 229.33. Such a message is commonly called a return item notification, and is processed through the Fedwire funds transfer system using a unique transaction type code and message format. The Board does not plan to change the check notice of nonpayment message format to the new structure because this business generally is conducted separately from the funds transfer business and utilizes different back-office systems. Changing the check return notification message format would require modification of the associated back-office systems and would impose costs on depository institutions without commensurate benefits. Some commenters believed that the new format should accommodate electronic tax collection initiatives, and one commenter specifically requested that Fedwire incorporate the ACH TXP (tax payment) format. One commenter prepared a detailed mapping recommendation. The Fedwire and ACH systems differ significantly with respect to the method of processing and the form of the data. While the Fedwire format is not able to substitute directly for any of the ACH payment formats, including the TXP format, the expanded format contains sufficient space to carry the details of a tax payment as currently defined by the Internal Revenue Service. Further, the Fedwire system may be used to make certain tax payments and may serve in an emergency back-up capacity to forward a tax payment that would normally flow through ACH; however, these tax payments must conform to the standard format used for Fedwire funds transfers. The Federal Reserve Banks will continue to study the evolution of the use of Fedwire to make tax payments; for example, the Federal Reserve Banks plan to incorporate a unique product code in the current format to assist depository institutions in structuring information within a designated field tag to facilitate this type of payment. The new format will incorporate this new tax payment product code, designated field tags and associated voluntary structuring, which will be described more fully in the CIPS document. A few commenters indicated that the new format should accommodate EDI capability; however, one commenter strongly objected to the use of Fedwire for EDI, noting that other suitable mechanisms already exist. The Board believes it is important that an expanded format recognize the need for certain information to travel with the payment. Although the expanded format may afford depository institutions with some ability to exchange EDI information, certain non-payment related activity is better suited to other types of communication systems. One commenter was concerned that some information may be truncated when mapping from the current format to the expanded format. This may occur because the space allocated in the third-party text portion of the current format may contain up to seven field tags or may be used for just one field tag. Space is allocated more discretely in the new format, so when only one field tag is used in the old format it is possible to exceed the number of available characters for the equivalent field in the new format. During the transition to the new format, the Fedwire software will map the excess characters into a new field defined to carry overflow information. A complete description of 14 the this mapping function will be provided in the CIPS document. Several other commenters requested clarification of some technical characteristics of the format. These clarifications will be addressed in the CIPS documentation. Details of the New Format. The expanded format can accommodate much longer messages than the current Fedwire format. For example, messages sent by a depository institution to the Federal Reserve Bank may contain approximately 1700 characters, compared to approximately 600 characters under the current Fedwire format. Intercepts—messages returned to the sending depository institution by Fedwire—and messages delivered by the Federal Reserve Bank to a receiving depositoiy institution may contain approximately 1800 characters in the expanded format, compared to approximately 700 characters today. Message length varies due to the information appended during processing by the Federal Reserve Banks. Field size in the new format has been increased and the field structure has changed. Each field has two parts: a tag that identifies the type of information a field may carry and elements that identify the specific piece of data within the field. The field tag must be one of the numeric codes designated for that purpose and the elements must be depicted in a specific order within the field. In general, elements are pieces of information that commonly follow a particular field tag, including but not limited to identifying information such as name, address, and account number. Valid elements are defined for each field tag. For example, the originator field has a field tag of [5000] that will be followed by elements, such as account number, name and address. The number of field tags in the new format is expanded greatly and incorporates the complete set of payment-related tags utilized by the current Fedwire format. The alpha tags in the current Fedwire format have been translated into numeric codes in the expanded format. For example, the beneficiary information field tag, denoted by BNF= in the current format, is tag [4200] in the expanded format. (The Glossary includes the field tag definitions and the Appendix lists the set of field tags.) Additional field tags have been defined to denote each of the standard fields in a message, including routing and technical information. For example, the IMAD (Input Message Accountability Data), which is assigned to a specific field position in the current Fedwire format, follows field tag [1520] in the expanded format. Elements, the information that follows a field tag, must be presented in a specific order within a field. The information either may be free form and of variable length, such as address, or may require a specific format, such as the business function code (product code), which must contain one of the eight defined acronyms. Each element within a field is allocated a specific amount of space; some elements are fixed in length, such as sender routing number, while others are variable in length, such as address. A delimiter element (*) always will follow a variable length element to denote the end of the element. No delimiter will follow a fixed length element. The elements convey information in a specific order and a combination of identifier code and field position is used to identify such information as account number. For example, the current format allows the identifier code, in this case /AC- (account number) to be used somewhere in the field following the beneficiary field tag, BNF=.../AC-123. In the new format, the beneficiary field tag [4200] may be followed by up to twelve elements: for example, the one character identifier code (first element); the identifier specified by the code, in this case an account number (second element); a delimiter, which is always an asterisk (third element); the beneficiary name (fourth element); and another delimiter (fifth element), such as [4200]D123*SMITH*. The identifier code is always the first element and identifies the type of number that follows it, in this case "D" represents account number. The identifier codes are defined in the Glossary. Although there are a large number of field tags defined in the new format, it is not necessary to use every tag in each message. The majority of the messages that a depository institution 15 will send—transfers where the originator is an account holder of the sending bank and the beneficiary is an account holder of the receiving bank-can be accommodated in a set of nine basic tags, depending upon how much originator and beneficiary information is provided. If the bank accepting the payment order from the originator is the institution sending the payment order to the Federal Reserve Bank, then it can be identified by routing number and short name in the field following the Sender FI tag [3100]. If the bank accepting the payment order for the beneficiary is the institution receiving the payment order from the Federal Reserve Bank, then it can be identified by routing number and short name in the field following the Receiver FI tag [3400]. For example, John Doe is sending $7,000 to his aunt, Sally Jones, who has an account at Bank Seven. John decides to send the money from his deposit account at Bank Away. John asks his account officer at Bank Away to send the money to his aunt at Bank Seven. The account officer has John’s name, address, and account number on file, and asks John to provide the same information for his aunt. John provides this information to his bank. John’s account officer at Bank Away prepares a payment order and forwards it to the funds transfer area for transmission over Fedwire: Amount: $7,000 Date: January 5, 1995 From: John Doe, account 6666123456, One Wayward Avenue, Watertown, MD; To: Bank Seven, Chicago, ABA 079999999, for further credit to account 899899, Sally Jones, 1920 Flapper Lane, Chicago, IL. Bank Away’s funds transfer area accepts the account officer’s payment order and prepares a corresponding payment order to send over Fedwire (in bold): Description TAG/ELEMENTS Sender Supplied [1500]MISCINFOHERE Information [1510]1000 Type/Sub-type [1520]0105E9999999000001 IMAD [2000)700000 Amount [3100J059999999AWAY* Sender FI [3320J9999999999999999 Sender Reference [3400]079999999BANKSEVEN* Receiver FI Business Function Code [3600JCTR Beneficiary [4200]D899899*SALLY JONES* 1920 FLAPPER LA* CHICAGO, IL* Originator [5000]6666123456*JOHN DOE* 1 WAYWARD AVE* WATERTOWN, MD* The expanded format also will provide ample space to include identifying information in a payment order to facilitate financial institution compliance with Treasury’s Travel Rule. For 16 example, the field following the originator tag [5000] has sufficient space, up to a maximum of 186 characters (including the tag) to include the originator’s account number, name, and address. The expanded format also provides more space to identify the bank that accepted the payment order from the originator; the bank routing number, name and address can be described in the field following originator’s financial institution tag [5100], up to a maximum of 186 characters (including the tag). The current format only provides a maximum of 61 characters to identify both the originator and the originating bank. Some Fedwire messages will be much larger and use more than the basic set of nine field tags to describe the parties to the transfer. For example, in cases where the originator and/or the beneficiary is a customer of a financial institution that is not a Fedwire participant, additional tags will be used to identify the originator’s financial institution, the beneficiary’s financial institution, and potentially also the instructing financial institution and the intermediary financial institution. If the customer of the originating bank is a nonbank financial institution, the originator tag [5000] and originator’s financial institution tag [5100] can be used to identify the transmitter and transmitter’s financial institution, respectively. In this case, the field following the originator tag [5000] can be used to reflect the transmitter’s account number, name and address. Information identifying the transmitter’s financial institution-the nonbank financial institution that accepts the transmittal order from the transmittor--can be included in the field following the originator’s financial institution tag [5100]. If the transmitter’s financial institution forwards the transmittal order to a financial institution that is not a Fedwire participant but utilizes a correspondent to access Fedwire, that institution’s identifying information, such as routing number and name, may follow the instructing financial institution tag [5200]. If the beneficiary’s financial institution is not a Fedwire participant, the sender may direct the payment order to a correspondent bank that maintains a relationship with the beneficiary’s financial institution. In such a case, the identifying information, such as routing number and name of the beneficiary’s financial institution, may follow the beneficiary’s financial institution tag [4100]. The correspondent will be identified in the field following the receiver financial institution tag [3400]. In the example below, John Doe is sending money to his aunt, Sally Jones. The money is being sent from his money market mutual fund account at Big Broker/Dealer, a customer of Ultimate Bank & Trust, which is a respondent of Bank Away, a Fedwire participant. Sally Jones is a customer of Local Credit Union, a respondent of Bank Seven. Further, Sally requests that John include instructions for the credit union to call her when the money is received. John’s account officer at Big Broker/Dealer has John’s name, address, and account number on file. John provides his aunt’s name and address, but is unaware of her account number. Big Broker/Dealer prepares a transmittal order and forwards it to its bank, Ultimate Bank & Trust. Amount: $7,000 Date: January 5, 1995 From: Our Account 767676, on behalf of our customer John Doe, account MMMF123456, One Wayward Avenue, Watertown, MD; To: Bank Seven, Chicago, ABA 079999999; for further credit to Local CU, 808 Watertower Center, Chicago, IL 60604, ABA 271011111; to credit its customer Sally Jones, 1920 Flapper Lane, Chicago, IL; Instructions: Phone advice—Ms. Jones (312)555-1212. Ultimate Bank & Trust accepts Big Broker/Dealer’s transmittal order, but is not a Fedwire participant, so it prepares a corresponding payment order, adding the address of Big/Broker 17 Dealer from its customer file, and forwards the payment order to Bank Away, its correspondent. Bank Away accepts Ultimate Bank & Trust’s payment order and prepares a corresponding payment order to send over Fedwire (in bold): Descriotion TAG/ELEMENTS Sender Supplied Information [1500]MISCINFOHERE Type/Sub-type [1510)1000 IMAD [1520J0105E9999999000001 Amount [2000)700000 Sender FI [3100)059999999AWAY* Sender Reference [3320)9999999999999999 Receiver FI [3400]079999999BANKSEVEN* Business Function Code [3600JCTR Beneficiary’s FI [4100)F271011111*LOCAL CU* 808 WATERTOWER CENTER* CHICAGO, IL 60604* Beneficiary [4200]DUNKNOWN*SALLY JONES* 1920 FLAPPER LA* CHICAGO, IL* Originator [5000)NMMMF123456*JOHN DOE* 1 WAYWARD AVE* WATERTOWN, MD* Originator’s FI [5100]D767676*BIGBROKER/DEALER* 222 CAMDEN YARDS CIRCLE* BALTIMORE, MD* Instructing FI [5200] F058888888*ULTIMATE * FI to FI Beneficiary’s FI Advice [6310JPHN ON RECEIPT* CALL MS JONES 312-555-1212* 18 The beneficiary tag [4200] and beneficiary’s financial institution tag [4100] also can be used to identify the recipient and recipient’s financial institution when the person to be paid by the transmittal order is the customer of a nonbank financial institution. In the example above, if John Doe had sent the money to his aunt in care of a currency exchanger, Money Swap, which also is a customer of Bank Seven, instead of the credit union, then the payment order sent to Fedwire would reflect the account number, name and address of Money Swap following the Beneficiary’s FI tag [4100]. The expanded format also accommodates inclusion of complete information received in an international (S.W.I.F.T. or CHIPS) transfer that must be forwarded over Fedwire. For example, on January 5, 1995, First Bronx NY receives a S.W.I.F.T. message from Black Forest Bank, Munich (S.W.I.F.T. identifier BBFBKDEZZ) to pay Cowboy Trust, Dallas for further credit to T. Edwards, account 123456 at the Rodeo Road Branch in Austin. The S.W.I.F.T. message indicates that Franz Mousse, doing business as Steak Palace, Maximillianstrasse 38, Munich, is paying T. Edwards $34,000 US, $10,000 on invoice TT33 for two cases of Texas T’s Bar-B-Q sauce and $24,000 as a franchise fee for use of the Texas T’s Secret Recipe. Black Forest Bank includes an instruction that states "Pay immediately. Do not deduct any related fees from the transfer amount—charge fee separately." First Bronx prepares a corresponding transmittal order and forwards it over Fedwire (in bold): Description TAG/ELEMENTS Type/Sub-type IMAD Amount Sender FI Sender Reference Receiver FI Business Function Code [1510]1000 [1520]0105B9999999000001 [2000]3400000 [3100]029999999FIRST BRONX NY* [3320]9999999999999999 [3400] 119999999COWBOYB ANK* Intermediary FI [4000]F029999999FIRST BRONX NY* Beneficiary’s FI [4100]F119999999*COWBOYBANK* RODEO ROAD BRANCH* AUSTIN, TX* Beneficiary [4200]D123456*T. EDWARDS* Originator [5000]DUNKNOWN*FRANZ MOUSSE* DBA STEAK PALACE* MAXIMILLIANSTRASSE 38* MUNICH, GERMANY* Originator’s FI [5100]BBFBKDEZZ*BLACKFORESTBK* MUNICH, GERMANY* [3600]CTR 19 Originator to Beneficiary Information FI to FI Receiving FI Information [6000JPAY T. EDWARDS $34,000 US,* $10,000 INV# TT33 2 CASES TEXAS T ’S* BAR-B-Q SAUCE, $24,000 FRANCHISE FEE* FOR TEXAS T ’S SECRET RECIPE* [6100]PER BLACK FOREST BANK* PAY IMMEDIATELY. DO NOT DEDUCT ANY* RELATED FEES FROM THE TRANSFER* AMOUNT-CHARGE FEE SEPARATELY* Competitive Impact Analysis The Board believes that this proposal will have no adverse effect on the ability of other service providers to compete effectively with the Federal Reserve Banks in providing similar services. Specifically, the Board believes that implementing the expanded format will have only a minimal effect on the operations of the CHIPS payment system. That is, CHIPS settlement participants will need to utilize the new format when sending and receiving settlement transfers through the Federal Reserve Bank of New York; however, these same depository institutions are also Fedwire participants and will utilize the new format to send and receive all Fedwire traffic. The Board also believes that the adoption of the expanded format will increase compatibility among CHIPS, S.W.I.F.T. and Fedwire. Increased compatibility facilitates the mapping of transfer information from one format to another when a payment order flows through multiple intermediary banks that use different funds transfer systems. Enhanced compatibility also broadens the range of choices that sending and intermediary financial institutions have when selecting a funds transfer system. By order of the Board of Governors of the Federal Reserve System, December 21, 1994. (Signed) William W. Wiles, Secretary of the Board. [FR Doc. 94-00000 Filed 00-00-94; 8:45 am] BILLING CODE 6210-01-P - 20 - GLOSSARY y « w toraat Current Format Definition Field tag used to indicate the date and time that the Fedwire application accepted the transfer; also includes the Fedwire application ID. Acceptance time stamp [ 1110] Adjustment [3000] Field tag used to carry the as-of date and reason for an adjustment; supplied by the Federal Reserve Bank granting the adjustment. Advice code An element consisting of a three character code, used in the FI to FI advice field to identify the method to be used to notify a party of the receipt of funds: LTR PHN TLX WRE Letter Phone Telex Wire Amplifying advice Information provided in the FI to FI advice fields used to facilitate the delivery of the payment notification, such as phone number and contact name. Amount [2000] Field tag used to indicate the amount of the transfer. (Note: There is an application edit that limits the transfer amount to one cent less than $1 billion.) Beneficiary [4200] BNF* Field tag used to identify the person to be paid by the beneficiary's financial institution. Beneficiary's financial institution [4100] BBK= Field tag used to identify the financial institution identified in the Fedwire message in which an account of the beneficiary is to be credited or which otherwise is to make payment to the beneficiary. 21 Ntw Format Current Format Definition Business function [3600] Product Code In the current format, a product code is the three character.code, followed by a slash, that identifies the purpose of the transfer. In the new format, the business function field tag is used to carry the three character code. BTR CTR CKS DEP DRW FFR FFS IRS Bank transfer— beneficiary is a bank Customer transfer— beneficiary is a nonbank Check same-day settlement Deposit to sender's account Drawdown Fed funds returned Fed funds sold IRS tax payment Charges [3700] Field tag used by the originator's financial institution to instruct a beneficiary's financial institution to deduct charges, if appropriate. Delimiter An asterisk (*) used to mark the end of variable length data. Element A specific piece of information carried in a field, which further identifies or defines the contents of a field. For example, the beneficiary field generally includes elements such as name and address. Error [1130] Field tag used by the Federal Reserve Bank returning a Fedwire transfer to the sender; includes an error code and description, such as "E185 INVALID TYPE/SUBTYPE." FI to FI [6100] to [6500] BBI= Financial institution to financial institution information field tags used to identify miscellaneous information pertaining to the transfer. In the new format, the FI to FI tags include information that commonly follows the BBI= tag and the advice method components of the IBK=, BBK=, and BNF= tags in the current format. The FI to FI tags are: Receiver FI information Intermediary FI information Intermediary FI advice info Beneficiary's FI information Beneficiary's FI advice info Beneficiary method of payment Beneficiary information Beneficiary advice info FI to FI information (generic) [6100] [6200] [6210] [6300] [6310] [6320] [6400] [6410] [6500] 22 Ntw Format Current F&raat Definition Field Field The portion of a message extending from a field tag to, but not including, another field tag or the end of the message. A field begins with a tag and, in the new format, is followed by one or more individual data items called elements. Field tag Field tag In the current format, the field tag denotes the beginning of third-party information, and is composed of four characters in the form aaa=, where "a" is a letter and an equals sign denotes the end of the tag. There are nine field tags in the current format. In the new format, the field tag denotes the beginning of any field (except for the interface code field). The tag is composed of six characters in the form [nnnn], where "n" is a number. There are 33 field tags in the new format. Identifier code The first element following a transfer party tag; a one character code that defines the type of identifier that follows it: N D B C F Nonbank (e.g. driver's license) Account number (e.g. deposit acct) Bank Identifier Code (BIC/SWIFT) CHIPS UID Code Routing number Identifier A variable-length element that identifies a party to a transfer, such as an account number or routing number. The identifier follows the identifier code in each field tag that identifies a party to the transfer. IMAD [1520] Field tag used to carry the Input Message Accountability Data. The IMAD is established at the time the message is first received by a Federal Reserve Bank, and includes a date, the logical terminal (Lterm) associated with the interfacing application that sent the message to Fedwire, an the sequence number assigned by the interfacing application. Intermediary financial institution [4000] IBK= Field tag used to identify the institution between the receiver FI and the beneficiary's FI through which the transfer must pass. 23 New Format Current Format Definition Instructing financial institution [5200] INS= Field tag used to identify the institution other than.the originator's financial institution that issues a payment order to the sending institution. Field used to indicate the type of communications protocol used by the application sending a transfer to a Federal Reserve Bank: Interface code X Z FLASH FRISC Message disposition [1100] Field tag used to carry certain message-related control information. The field has four elements: format version, test/production code, message duplication code, and message status indicator. OMAD [1120] Field tag used to carry the Output Message Accountability Data. OMAD is established at the time the message is queued for delivery by a Federal Reserve Bank, and includes the date, the logical terminal (Lterm) associated with the interfacing application that will receive the message from Fedwire, a sequence number, a time stamp, and a code identifying the Federal Reserve Bank delivering the message. Originator [5000] ORG= Field tag used to identify the sender of the first payment order in a funds transfer. Originator's financial institution [5100] OGB= Field tag used to identify the financial institution to which the payment order of the originator is issued. Originator to beneficiary information [6000] OBI= Field tag used to identify information conveyed from the originator to the beneficiary. Previous Message IMAD [3500] Field tag used to reference the IMAD of an earlier transfer when the sender is returning, correcting, or otherwise referencing a transfer previously sent or received. Receiver financial institution [3400] Field tag used to carry the nine digit routing number and short name of the financial institution that received the transfer from a Federal Reserve Bank. Reference for beneficiary [3321] RFB= Field tag used to provide reference information that enables the beneficiary to identify the transfer. - 24 K«w Format Current Format Definition Sender financial institution [3100] Field tag used to carry the nine digit routing number and short name of the financial institution that sent the transfer to a Federal Reserve Bank. Sender reference [3320] Field tag used to carry the sending financial institution's reference number. Sender supplied information [1500] Field tag used by sender financial institution to carry the following three elements: user request correlation data, test/production code, and message duplication code. Special handling instruction [1140] Field tag used by the Federal Reserve Bank to insert special handling instructions. Type/Subtype code [1510] Field tag used to indicate the transfer type and sub-type. Type code values: 10 Third-party funds transfer 15 Foreign transfer (foreign central banks and international agencies) 16 Settlement transfers Sub-type code values: 00 Transfer 01 Request for reversal 02 Reversal of transfer 07 Request for reversal of prior day transfer 08 Reversal of prior day transfer 20 As-of adjustment 31 Request for credit transfer (drawdown) 32 Funds transfer honoring request for credit transfer 33 Refusal to honor request for credit transfer 90 Service message - 25 Appendix Mew Fedvire Funds Transfer Format Field Tags Size* Tag Number Tag Description* Required/ Optional Field* none“ Interface code Appended 1 [1100]“ Message disposition Appended 9 [1110]“ Acceptance time stamp Appended 18 [1120]“ OMAD Appended 36 [1130]“ Error Appended 46 [1140]“ Special handling instructions Appended 33 [1500]“ Sender supplied information Required 18e [1510]“ Type/Subtype code Required 10 [1520]“ IMAD Appended 24 [2000] Amount Required 24 [3000] Adjustment Optional 14 [3100] Sender FI Required 34 [3320] Sender reference Required 23 [3321] Reference for beneficiary Optional 23 [3400] Receiver FI Required 34 [3500] Previous Message IMAD Optional 24 [3600] Business function Required 9 [3700] Charges Optional 9 [4000] Intermediary FI Optional 186 [4100] Beneficiary's FI Optional 186 [4200] Beneficiary Optional 191 [5000] Originator Required 186 [5100] Originator's FI Optional 186 [5200] Instructing FI Optional 186 26 1 Tag | Number Tag Description* Required/ Optional Field" | [6000] Originator to beneficiary information Optional 150 Optional 222 [6100] 1 [6200] [6210] [6300] [6310] [6320] [6400] [6410] [6500] FI to FIs Receiver FI information Intermediary FI information Intermediary FI advice information Beneficiary's FI information Beneficiary's FI advice information Beneficiary method of payment Beneficiary information Beneficiary advice information FI to FI information (generic) Size* H a. For purposes of comparison, a description of the current format and required fields is contained in the Computer Interface Protocol Specifications (CIPS) pages 5.8.1, 5.8.2., and 5.8.9. b. Mandatory fields are marked "required;” fields that may be omitted are marked "optional;" and those fields appended by Fedwire processing are marked "appended." In general, optional tags may be omitted, but sometimes are specifically required by the structured third-party funds transfer format rules. For example, if there is information in the originator [5000] field, there must be related information in the originator's financial institution [5100] field. The complete set of structured third-party funds transfer format rules, revised to reflect the new field tags, will be published in CIPS. c. The maximum field size includes the six character field tag. d. The interface code and fields with tags in the 1000 series are designed to carry technical information. The content and purpose of these tags and fields will be defined more fully in the new CIPS. e. Field will contain 16 characters in an intercept message because format code is omitted. FEDERAL RESERVE SYSTEM [Docket No. R-0778] Federal Reserve Bank Services AGENCY: Board of Governors of the Federal Reserve System. ACTION: Notice. SUMMARY: In February 1994, the Board approved the expansion of the Fedwire on-line funds transfer service operating hours to 18 hours a day, from 12:30 a.m. to 6:30 p.m. Eastern Time (ET), beginning in early 1997. Currently, the Fedwire funds transfer service operates 10 hours a day, from 8:30 a.m. ET to 6:30 p.m. ET. The Board has delayed the implementation of the expanded Fedwire on-line funds transfer operating hours until fourth quarter 1997 to provide banks that intend to participate during the expanded hours an opportunity to first complete their conversion to the new Fedwire format. The Board believes a modest delay in the implementation of the earlier Fedewire opening time will be sufficient to address industry concerns regarding the interdependencies between the two Fedwire initiatives, while not deferring for a significant period of time the potential changes in payments and settlement practices that can contribute to reductions in Herstatt risk. A specific implementation date will be announced one year in advance of the effective date. FOR FURTHER INFORMATION CONTACT: Louise L. Roseman, Associate Director (202/4522789), Gayle Brett, Manager (202/452-2934), or Lisa Hoskins, Project Leader (202/452-3437), Division of Reserve Bank Operations and Payment Systems. For the hearing impaired only. Telecommunication Device for the Deaf (TDD), Dorothea Thompson (202/452-3544). SUPPLEMENTARY INFORMATON: In February 1994, the Board announced approval of the expansion of the Fedwire on-line funds transfer service operating hours to 18 hours a day, from 12:30 a.m. to 6:30 p.m. Eastern Time (ET), beginning in early 1997.1 (59 FR 8981, February 24, 1994) In its announcement, the Board identified two public policy objectives for the Fedwire funds transfer service. Fedwire should: (1) Provide a means that can be used to enhance the safety and efficiency of the U.S. dollar settlement arrangements, including arrangements that rely on interbank settlement of netted positions, particularly during periods of financial stress, and (2) Respond to the needs of both existing and emerging financial markets, including overseas markets, which depend on the U.S. dollar and are increasingly reliant on state-of-the-art technology. With these public policy objectives in mind and after extensive contact with representatives of commercial banks, brokers and dealers, clearing organizations, and corporate treasurers, the Board concluded that expanded Fedwire funds transfer operating hours could be a useful component of private-sector initiatives to reduce settlement risk in the foreign exchange markets. In addition, the Board concluded that expanded Fedwire funds transfer operating hours will eliminate an operational barrier to potentially important innovation in privately-provided payment and settlement services. 'Currently, the Fedwire funds transfer service operates 10 hours a day, from 8:30 a.m. ET to 6:30 p.m. ET. 2 ,4 At the same time, the Board recognized the need stressed by the industry representatives that a long lead-time would be necessary for banks to make the necessary investments in new technology and the modifications to operating procedures in preparation for participating in expanded funds transfer operating hours. In particular, many banks would need to make significant automation and procedural changes in their end-of-day processing, which includes many batch operations, in order to obtain opening-of-business customer account balances earlier than they do today. Thus, when announcing the earlier Fedwire opening time, the Board indicated that the expansion would not take place until early 1997 and that a specific implementation date would be announced one year prior to the expansion. Subsequent to the Board’s February announcement, the Board received comments on a proposal to expand the Fedwire funds transfer format. (58 FR 33366, December 1, 1993) The Board had proposed completing the implementation of the new format by year-end 1996; many commenters requested a longer period of time to complete this conversion. In addition, commenters expressed the desire to complete the conversion to the expanded format prior to the expansion of Fedwire funds transfer operating hours. These commenters indicated that it would be burdensome for them to pursue both initiatives simultaneously as many of the same automation and human resources would be necessary to accomplish both initiatives. Board and Reserve Bank staff recently discussed with representatives of money center and regional banks the interdependencies between these two Fedwire initiatives. In these discussions, bankers indicated that, despite the Board’s statement that participation in expanded Fedwire funds transfer operating hours will be voluntary, they believe that competitive pressures will mandate their participation. Some of these bankers also indicated that they needed to modify their systems to provide a means to send during the early hours only those funds transfers destined for banks that are open during the early hours. In addition, some bankers indicated that they intend to provide a mechanism by which their customers can designate which of their funds transfers should be sent during the early hours. Some of the bankers indicated that they did not want to make changes to the customer interface to their current Fedwire software, when soon thereafter they would have to change that software (and the customer interface) to accommodate the new Fedwire format. These bankers indicated that the implementation of expanded operating hours should follow the new format after a lag; suggested time frames were as short as three months and as long as twelve months. Separately, bankers and representatives from clearing organizations have indicated in a variety of forums that steps should be taken to reduce Herstatt risk and that such steps can take advantage of expanded Fedwire funds transfer operating hours. For example, the New York Clearing House recently announced that it is evaluating a possible earlier opening time and multiple settlements for the Clearing House Interbank Payments Systems (CHIPS). In addition, Multinet International has indicated that it plans to take advantage of earlier Fedwire operating hours to settle dollar obligations arising from its proposed netting service. The Board has considered whether to delay somewhat the implementation of expanded funds transfer operating hours. Such a delay could reduce the operational burden on banks in complying with this initiative in light of the new funds transfer format, but also would withhold the potential benefits from banks and clearing organizations that intend to use the expanded funds transfer operating hours in developing solutions to reduce Herstatt risk. 3 The Board believes that the majority of banks that may intend to participate in the early funds transfer operating hours will be the same banks that are likely to complete their conversions to the new Fedwire funds transfer format early in the implementation schedule. The Board has approved an expanded Fedwire format and an implementaion schedule for conversion to the new format. (See notice elsewhere in today’s Federal Register.) Based on the approved implementation schedule for the new format, the earliest that banks can complete their format conversion is June 23, 1997.2 It is possible that some banks wanting to participate in expanded operating hours likely would not be converted totally to the new format until later in 1997. The Board believes that a modest delay in the implementation of the earlier Fedwire opening time would be sufficient to address concerns raised by the larger banks regarding the potential operational burden of implementing these two initiatives concurrently, while not deferring for a significant period of time the potential changes in payments and settlement practices that can contribute to reductions in Herstatt risk. Therefore, the implementation of the expanded Fedwire funds transfer operating hours will be delayed until fourth quarter 1997. A specific implementation date will be announced approximately one year in advance of the effective date. A late 1997 implementation of expanded Fedwire funds transfer operating hours will provide an approximate four-month lag for those banks that choose to complete their Fedwire format implementation early in the conversion schedule. By order of the Board of Governors of the Federal Reserve System, December 21, 1994. (Signed) William W. Wiles, Secretary of the Board. [FR Doc. 94-00000 Filed 00-00-94; 8:45 am] BILLING CODE 6210-01-P 2The implementation plan for the new Fedwire format consists of a two-phased implementation wherein participants begin receiving Fedwire transfers in the new format before they begin sending new-format transfers. The implementation plan also will allow a subset of institutions to implement both the receive and send capabilities on a same-day basis on the first day of the second phase.
@FedFRASER