Porting In/Out
      Back to home
      1. Knowledge Base
      2. Repository - CFTC SDR
      3. Porting In/Out

      How do I port swaps to KOR SDR?

      What is the Porting Process?

        1. At least five Business Days prior to porting into KOR SDR, the Client must provide notification in writing to KOR SDR of their intention to port in (support@korfinancial.com) (or via a ticket). Such notification shall include:
            1. The UTIs/USIs of the swaps porting;
            2. Planned porting date;[1] and
            3. Indication if the Client is porting all swaps or only open swaps.
        2. Execute the KOR Universal Services Agreement and applicable annex(s).
        3. Administrative User must set up all User access (Create and manage a user as an admin)
        4. Client must complete all steps and port out trades from their current SDR on the same date trades are ported into KOR SDR. This includes reporting the change of SDR to the SDR to which the reporting counterparty is currently reporting swap and pricing data as a lifecycle event for such swap pursuant to § 45.4 using [Action type] = ‘PRTO’ and [Event type] = ‘PTNG’.
        5. On the same day, the reporting counterparty shall report a Transaction message for the same swaps to the new SDR with [Action type] = ‘NEWT’ and [Event type] = ‘PTNG’. Note that the transaction is reported using the same UTI (or USI where applicable) and same execution timestamp. 
          1. KOR only accepts open swaps for porting in by a Client.
          2. All swaps must meet the standards of the current KOR SDR Technical Standards.
          3. All swaps shall be reported in their current state.
        2. Before a publicly disseminated event on a ported in message can be submitted, the reporting counterparty shall also report a Public Message for that swap with [Action type] = ‘NEWT’ and [Event type] = ‘PTNG’. This can either be done when the Transaction messages are first reported or at the time an update needs to be publicly disseminated. 
          1. Note that the Public message with [Action type] = ‘NEWT’ and [Event type] = ‘PTNG’ will not be publicly disseminated. See Related Article for more information. 

      If a Reporting Counterparty ports swaps in from another SDR that used a substitute identifier, those swaps shall be ported in using the correct LEI, or if the party is not eligible for an LEI, then the Natural Person Identifier. 

      If a Reporting Counterparty ports swaps in from another SDR that were reported under a USI, then they should be ported using the USI field. KOR only accepts USIs on ported in swaps and not NEWT swaps. NEWT swaps that are not ported in shall only use a UTI. 

      Reference CFTC Rule 45.10(d)(1).


      -------------------------------------------------------------------------------------------------------------

      [1] KOR SDR has the right to request the Client select another date if they need KOR Client support if KOR has already committed support to other activities (e.g., other porting Clients, technical release, systems testing, or holiday schedules).

      A Client may elect to start submitting new swaps to KOR SDR prior to porting in all open swaps.

      Can I report to two SDRs at one time?

      Yes. 

      You may elect to start reporting new swaps to KOR SDR and then port your open swaps over at a later date, but during that time you must continue to report all continuation data to the SDR where the swap resides.

      What data can I port into KOR SDR?

      KOR SDR only accepts open swaps for porting in. This includes any open uncleared bilateral and cleared swaps. When porting in a cleared swap, please note that the original terminated bilateral (alpha) must not be ported and should remain with the original SDR. 

      What are the regulatory requirements around the porting procedure?

      The Reporting Counterparty shall report the change of Swap Data Repository to the Swap Data Repository to which the Reporting Counterparty is currently reporting Swap Transaction and Pricing Data and Swap Data as a life-cycle event.

      On the same day that the Reporting Counterparty reports required swap continuation data, the Reporting Counterparty shall also report the change of Swap Data Repository to the Swap Data Repository to which Swap Transaction and Pricing Data and Swap Data will be reported going forward as a life-cycle event for such swap. The required swap continuation data report shall identify the swap using the same unique trade identifier used to identify the swap at the previous Swap Data Repository.

      Thereafter, all Swap Transaction and Pricing Data, required swap creation data, and required swap continuation data for the swap shall be reported to the same Swap Data Repository, unless the Reporting Counterparty for the swap makes another change to the Swap Data Repository to which such data is reported.

      References: CFTC Rule(s) §45.10(d)(2).