Confirming natural gas nominations

Is it better to confirm at a shipper level or a nomination level or something in between?

The level of detail of confirmations can cause chaos on a pipeline during a process that has a very finite window.  Confirmations occur at a location where gas is received onto a pipeline or delivered off of a pipeline. The confirmation takes place between the interconnected parties at the location. One of the parties requests the confirmation and the other party responds with the confirmed transaction quantities.  If the parties cannot agree on which party will be the requester and which will be the confirming party, then both parties will issue the request and both parties will respond.

The party requesting the confirmation determines the level of detail in the request.  The confirmation dataset allows the request to contain, minimally, one shipper – either the upstream or downstream party, depending on direction of flow.  The dataset also allows the confirmation requester to include shipper contract, upstream and downstream contracts, associated contracts, package ID and upstream and downstream package IDs.

There are a lot of variables in the confirmation.

On one pipeline, the pipeline may receive a request for confirmation, for one location, at the shipper level; for a second location, identifying the shipper, shipper contract, and upstream or downstream contract; and for a third location, identifying the shipper, shipper contract, upstream or downstream contract, package ID and upstream or downstream package IDs. In the third example, the interconnected party is confirming at an equivalent to the nomination level.

Let’s use the upstream pipeline as our interconnected party for an example.  If that upstream pipeline confirms at the nomination level, then the confirming party has told us which nominations to cut and which to keep whole based on our pipeline nominations.  In a worst case situation, they could be cutting nominations on a firm contract that the shipper ranked as top priority and the upstream pipeline is making that decision on our pipeline. That doesn’t make sense.

Confirming at a nomination or package ID level is bad.

Using our same example, suppose we are confirming at a shipper + shipper contract – to – upstream shipper + upstream contract level.  The upstream pipeline is going to make sure that the service level on their pipeline is met first.  If their shipper (the upstream shipper from our point of view) is shipping on a firm contract, then the pipeline’s duty is to keep it whole if possible.  But the same party is delivering to the interruptible contract for a shipper on our pipeline. So the pipeline may be telling us to keep an interruptible contract whole for our shipper while cutting a firm contract.  That doesn’t make much sense either.  It is important to note, though, that this is the most common method of confirmations used today.

Confirming at a shipper contract level is bad.

Back to the same example.  Suppose we are confirming at a shipper – to – shipper level.  The upstream pipeline will total the quantities for their shipper, across all of their contracts. The confirming party will tell us the quantities being guaranteed for each of the shippers. Now we can use our pipeline tariff priorities to determine which of the shipper’s transactions are confirmed and which are cut. This means that our contract priorities are used first, so that the shipper’s Firm transactions can be confirmed first. This also means that inside of a contract, the shipper provided ranks can be used to tell us which of the nomination line items should be cut if a cut needs to occur.