by sylviamunson

The Aggravation of Nomination Aggregation in the Pathed Non-threaded Nomination Model

Four-score and seven years ago – okay, really – only one score of years ago – when the Pathed Non-threaded (PNT) Nomination Model was created it was an outlier model type used by one company.  Today that model type is used by many companies and is becoming the source of a lot of interpretation.

There are problems with the way the model type is being implemented today and there are two factors contributing to this problem. We’ll look at them individually then pull them back together to find a solution.

Factor 1:

The Service Requester Contract (SrK) is mandatory on the upstream and downstream nominations of the PNT model and it should not be. Kinder Morgan, Boardwalk and Iroquois have submitted a request to have this changed.

When the model type was created, for NGPL, the NGPL representative, Mike Schisler, explained that the shipper contract (NAESB term = Service Requester Contract) had no meaning on the upstream and downstream nominations of the PNT model.  But the data set designers insisted that it remain. The compromise was that NGPL would fill that field with the service requester’s DUNS number.  That solution has worked for NGPL for many years even though many of us in the industry as well as more recent implementers did not understand the real impact of the decision. The solution implemented by other pipelines varies, is inconsistent, and provides for unintended inconsistencies.

Note that I do not believe there is any documentation in the NAESB standards or implementation guides that specifically says the SrK should be filled with the service requester’s DUNS number.  This was only an “understanding” – which adds an additional level of confusion and was not conveyed to other parties attempting to implement the model in the same way.

Factor 2:

The Service Requester (SR) is defined as the shipper or their agent.

There is one field for a Service Requester on a nomination.  My understanding has been that if the shipper is submitting their own nominations then they will provide their own identifier as the service requester.  If the agent is submitting nominations for a shipper then the agent identifier will be used in the service requester field and the service requester contract will be used to distinguish shipper rights for that agent.

Basic Math:

When we add these two factors together in the model type, you would think that we’d get 3 simple variations since both are mandatory.  SrK used + SR Agent, SrK used + SR Shipper, SrK DUNS + SR.  Not so!  What we’ve seen in the industry is that we have 4 (rumor is that there may be a 5th) variations of how pipelines use these fields to define nominations for the upstream and downstream nominations of the PNT model.

Pipeline Scenario 1:

SR = Agent, SrK = agent DUNS

Result:

I have to admit – this is the way that I thought that the PNT model should work when an agent was engaged.  I did not initially recognize the implication of this scenario.  If I, idealistically, apply the definition of the SR and then use the rule of putting the SR’s DUNS into the SrK field then the result is this scenario.

However – if you consider a group of upstream nominations at a receipt location where all of them are designated for the agent, then how does the pipeline determine which transactions belong to which shipper and how is shipper-must-have-title rule being followed?  This would be a plausible solution if the agent has asset-manager rights but not for a traditional shipper agent.  This forces the agent into what I would call an agent-level aggregation where all of the agent’s transactions at a location are aggregated under that agent and not distinguishable by shipper.

Pipeline Scenario 2:

SR = Agent or Shipper, SrK = shipper DUNS

Result:

This scenario works the way that I believe the model type was originally intended but it has to abuse the data elements in order to make the model type work.  In this scenario, all of the quantities for one shipper are aggregated at a location so that they can then be distributed among the threaded, contract-specific nominations on the other side of that same location.

If the shipper is the SR then this scenario is clean and easy, though the pipeline is still forced to repeat the shipper DUNS in the SrK field.  When the agent is the SR is where the information becomes muddy and where it becomes obvious that an additional data element, to distinguish the agent from the shipper, is necessary.

Some pipelines have solved this scenario by using the EDI enveloping to identify the agent and, then, identifying the shipper in the SR field.  This works, but it is another forced use of the data elements in a way they were not intended to be used.

Pipeline Scenario 3:

SR = Agent or shipper, SrK = shipper contract

Result:

If the pipeline has chosen to use the shipper contract on the upstream and downstream nominations then the issue of whether the party identified in the SR field is nullified.  The level of nomination aggregation has been taken to a lower, contract level, and the contract for aggregation has been identified.  This contract-level aggregation does not provide as much flexibility for the shipper, but all of the data needed to accomplish the task is included.

However, even though the SrK solves the problem, the solution should be consistent across all of the nomination models and model usages.

Pipeline Scenario 4:

Any of the above plus Threaded Nomination association

Result:

I am including this scenario because I have seen several companies implement the PNT model in this way even though the data in the transaction does not support this implementation! In this scenario, the upstream and downstream nominations are directly tied to a threaded nomination.  This is essentially a pathed-nomination in most examples where a single upstream is tied to a single threaded nomination and a single downstream, but the implementation does allow for two or more upstream or downstream nominations to be tied to that middle threaded nomination.  There is no aggregation at the contract or shipper level in this scenario because the upstream and downstream nominations are tied to an individual threaded nomination.

Again – the data in the dataset does not support this implementation.  The implementer has to create an artificial connection to tie the various nominations together. The artificial solutions that I have seen are through tracking id’s, package id’s or through the use of a pipeline-managed database internal id that is not maintained by the shipper.  This scenario would be impossible to implement using EDI in the existing dataset.

So where does this leave us?

We need a solution so that shippers know what to expect. We need a solution so that the implementations of the model type can be clean and consistent. We need to add and define the data in the dataset so that it fully supports the model type. We can continue to perpetuate some of our incorrect decisions, but, ultimately that does not buy any efficiency, it allows us to continue with bandaids as solutions.

Here are my suggestions:

1              Split the current “Service Requester” data element into two fields:

Service Holder or Shipper and

Agent

Service Holder/Shipper could either be mandatory in all cases, or conditional with a condition that it is mandatory except where a pipeline supports agent-level aggregation and the nominating party has provided an Agent DUNS. I would prefer mandatory and let the pipeline implementation determine how the shipper information is used.

Agent would be conditional – either an agent or service holder must always be provided and Agent is required if the party submitting the nomination is different than the party holding the service contract.

2              As Kinder Morgan, Boardwalk and Iroquois have requested, make the service requester contract a business conditional data element on the upstream and downstream nominations of the PNT model.  It should remain mandatory for all other cases.  It should only be used on the PNT model’s upstream and downstream nominations if the pipeline supports contract level aggregation. Otherwise, it is not used.

3              Make it clear in the nomination implementation guides that there are three levels of aggregation and that a pipeline will generally only support one of those levels.  The three levels are Agent-level aggregation (give an example), Shipper level aggregation (give an example) and Contract level aggregation (give an example).  If parties desire the dataset support additional levels of aggregation then those parties need to submit a request to NAESB for the requirements of that aggregation level to be supported.

 

 

 

by sylviamunson

Choose to be Creative – 6 Ideas for Consolidating the Confirmations Process in Natural Gas

FERC Order 809 occupies a large share of the time I allot to “what’s next” thinking.  There are so many opportunities inside what the FERC has assigned the industry in Order 809.

Let’s put our thinking caps on and get creative!

Confirmations

In Order 809 the FERC asked us to “. . . explore the potential for faster, computerized scheduling when shippers and confirming parties all submit electronic nominations and confirmations, including a streamlined confirmation process if necessary.”  The discussion here is the reference to submittal of electronic confirmations.  There are some pipelines in the gas industry today that have made great progress in implementation of electronic confirmations through EDI. But there are others who have not done any electronic confirmations and, generally, electronic confirmations are executed between interstate pipelines.

So what can we do?

1 – Is there an opportunity for XML to become the standard for confirmations so that it is less expensive to implement and more web-enabled?

2 – Do we need confirmation-clearing companies such as those used in trading?

3 – Do these streamlined confirmations need to cover the entire natural gas supply chain or do they only need to apply to deliveries to electric generation and their suppliers? Do electric generation suppliers only need to confirm upstream to the nearest point of on-demand supply, such as storage, park-and-loan, etc.?

4 – Is there a new on-demand service offering that would provide a service to supplant streamlined confirmations?

5 – Are there new confirmation services that can be offered to expedite the process while still providing reliable delivery?

6 – Should electric generators be allowed to submit hourly nominations and, consequently, incur hourly imbalances to minimize the number of intraday confirmations?

On September 17th the FERC issued an Order on Rehearing (Docket No. RM14-2-001) where they stated “…the Commission requests that the natural gas and electric industries, through NAESB, begin considering the development of standards related to faster, computerized scheduling and file such standards or a report on the development of such standards with the Commission by October 17, 2016.” This gives us a deadline to work toward.  Deadlines are good.  It also give us a lot of time to get the job done.  So let’s start thinking about this assignment.

by sylviamunson

Fun with FERC Order 809 continued – or – “Continuous and Contiguous Scheduling”

We have an interesting challenge ahead of us. One of the take-aways of FERC Order 809 is the requirement for the North American Energy Standards Board (NAESB) to look at and consider ways to make natural gas pipeline scheduling faster and closer to real time. Electric generators have made it clear that they need more flexibility with scheduling as they move more electric generation to a natural gas dependency.

This is not a new idea. It has been tossed about more than once before Order 809. One of the very first principles written by NAESB in GISB Version 1.0 in the mid-1990’s was Principle 1.1.2 which states “There should be a standard for the nominations and confirmations process. Agreement notwithstanding, it is recognized that this is an interim step to continuous and contiguous scheduling.”    (Copyright North American Energy Standards Board, NAESB Version 3.0 published 2014)

NAESB quickly, in Version 1.0, created the standardized Nominations and Confirmations processes including a few touches on the scheduling process in that mix.  A great step was made when NAESB added the Intraday Cycles and now, via NAESB 3.0 and Order 809, there is an additional Intraday Cycle giving shippers a total of 5 nomination opportunities in the day-ahead and day-of scheduling process.

And that’s not all.

Some pipelines have already implemented multiple scheduling cycles throughout the day that are in addition to the NAESB cycles.  A few pipelines have gone so far as to create hourly cycles. But without a consistent solution, the ‘contiguous’ side of scheduling becomes difficult.

Not all pipelines have gone beyond the standard cycles. So, what do we do?  Are we ready for that ‘Continuous and Contiguous’ process that we considered so long ago?

I believe we are. I believe that it will require some serious paradigm-shift-type thinking to make it happen.

The actual excerpt from Order 809 is below, from the Commission request, and as noted in paragraph 107:

However, the use of computerized scheduling would appear to provide an opportunity for faster and more frequent scheduling of intraday nominations for those shippers and their confirming parties willing to commit to scheduling electronically. We request that gas and electric industries, through NAESB, explore the potential for faster, computerized scheduling when shippers and confirming parties all submit electronic nominations and confirmations, including a streamlined confirmation process if necessary. Providing such an option would enable those entities that need greater scheduling flexibility to have their requests processed expeditiously.

What are the opportunities here?

  • If we converted the nomination and confirmation processes to XML based transactions and generated the confirmation request straight from the requested nomination then we could have more immediate communication and create that contiguous chain.
  • If we kept our traditional ‘Timely’ Scheduling cycle, possibly even the ‘Evening’ cycle and then, after that, opened the process to a first come, first serve processing with a quick turnaround, then we could eliminate the interim cycles and provide that continuous service.
  • We would still need a no-bump cutoff where IT shippers could count on their gas to flow. Possibly at the time of the current cutoff already agreed to in NAESB.

These ideas require major technology investments. These are just a few ideas. I have others, but I’d like to hear from other people first.

The NAESB Board has voted to make this aspect of Order 809 a primary topic in 2016.  As an industry, we need problem solvers to step up and create straw man solutions before those NAESB meetings begin.  Let’s get the discussion started.

by sylviamunson

The Deep, Deep Details – Transaction Types

Do I need to apologize first for this post?  This post gets deep in the weeds of data interaction on the nomination transaction.  But somewhere, somehow, someone has to get down in the weeds to explain why people keep tripping over transaction types.  It has to be said! So here it comes.

Transaction Types are data values on nominations that indicate the shipper’s usage for the quantity that is being requested.  That’s Sylvia’s definition and it assumes you know what a nomination is and who is a shipper.

The standard default transaction type in nominations is ’01 – Current Business’, meaning that this transaction uses the general terms of the contract.  There are over 100 transaction types available in the North American Energy Standards Board (NAESB) Nomination dataset, but a single pipeline will usually support only 5-10 of those types.

Okay – that’s easy – what’s the big deal?  There are, actually, two big deals.  The first is that the transaction type can occur on each nomination in each model type and this opens the door for confusion and varied interpretations.  The second is that there are three different transaction types – Transaction Type, Upstream Transaction Type and Downstream Transaction Type – and people tend to make assumptions regarding their meaning.

The first issue:

A pathed nomination uses one nomination line item to transact business and, therefore, one transaction type.  Easy.

A non-pathed nomination uses two nomination line items to transact business and, therefore, two transaction types.  So we need to have rules in place on what transaction types are used in which situation and how they are balanced.

Then we get to the pathed non-threaded nomination and see that it uses three nomination line items to transact business and three transaction types.  Now things are starting to look complicated.

Let’s look at a few of the most commonly referenced transaction types.  These would be the ’03 – Imbalance Payback from TSP’ and ’04 – Imbalance Payback to TSP’.  Note that TSP in this case stands for Transportation Service Provider.

If you are submitting a pathed nomination and want to use ‘03’ to receive 500 DTH of gas back from the TSP then you’ll submit a nomination with zero as the receipt quantity and 500 as the delivery quantity.  Clear and easy.

If you are submitting a non-pathed nomination then you won’t need to enter an upstream nomination but you’ll enter a downstream nomination with ‘03’ transaction type and 500 DTH as the quantity.  In this case the payback is coming from the pipeline’s linepack volume and there is no need for a receipt type nomination to balance the transaction.  Still clear and easy.

So what happens if you are submitting a pathed non-threaded nomination?  My first choice would be for you to enter a downstream non-pathed nomination with ‘03’ as the transaction type and the quantity of 500 DTH on the downstream non-pathed nomination.  The corresponding pathed nomination and the upstream non-pathed nomination would be with ’01 – Current business’ as the transaction type and would contain either zero or the quantity that needs to be transported.  This seems pretty clean because the shipper is only telling the pipeline where the payback gas needs to be taken off the pipeline, without association to any transportation or supply of gas.  The second choice that I have seen in implementations is to create, essentially, a whole path of gas for this ‘03’ transaction type.  In this implementation, the shipper would create an upstream non-pathed nomination with a quantity of zero, a pathed nomination with a receipt quantity of zero and a delivery quantity of 500, and a third nomination as the downstream non-pathed with a quantity of 500.  All three of these nominations would have the transaction type of ‘03’.  This second choice is technically correct and do-able, but it puts a lot of extra work on the shipper and unnecessarily ties the payback transaction to a path of gas that is not needed.

There are other transaction types which cause these same scenarios, but NAESB and most pipelines do not give clear instructions on how they are used.  This leaves room for interpretation – a dangerous game.  Interpretation results in different pipelines solving the same problem in different ways and  different shippers trying solutions that the pipeline doesn’t expect.  This makes it hard for everyone involved to get the results they expect.

The second issue:

There are three (3!) different transaction types available on the model types.  For a long, long time there was only one transaction type and it was called Transaction Type.  As NAESB standards progressed, pipelines asked for an Upstream Transaction Type and Downstream Transaction Type to be added for the confirmations process.  The Upstream and Downstream Transaction Types, if you look up the NAESB definition, do NOT refer to the business being conducted on the current pipeline. The Upstream Transaction Type refers to the transaction type on the pipeline Upstream of the current pipeline. The Downstream Transaction Type refers to the transaction type on the pipeline Downstream of the current pipeline.  Interestingly, people look at the name and think that the Upstream Transaction Type must go on the Upstream Nomination in the Non-Pathed and Pathed Non-Threaded Model types but this just isn’t so.  The Upstream Transaction Type can go on the Pathed or Non-Pathed Model but NAESB clearly states that it is referring to the transaction type of the nomination on the upstream pipeline.  All of the same logic/rules apply to the Downstream Transaction Type, of course.  And, the Upstream and Downstream Transaction Types do not exist on the Pathed Non-Threaded Model Type at all!

Clearly looking at the definition of data elements is essential before assuming their meaning or intent because the name is not always the only indicator of the purpose.  Nominations are complex transactions.

by sylviamunson

Fun with FERC Order 809 or “How to Put Two Shippers on One Contract” . . .

The Federal Energy Regulatory Commission (FERC) recently issued Order 809 for interstate pipelines. One of the components of the order was for pipelines to support the ability for a Firm transportation contract to have multiple shippers.  The good news is that the pipeline only has to support this ability IF shippers request the service.  The bad news is that the pipeline only has 60 days to implement the service once it is asked for.  This means that the pipeline has to be prepared to offer the service because I don’t know of many pipelines who can implement such a change in just 60 days.

So why on earth would you need two shippers in a contract?  I can imagine several scenarios where this could be advantageous.  For instance, if a shipper needs reliable firm service on an as-needed basis and can find another shipper, such as a marketer, to utilize the un-used firm.  The would give the first shipper the reliability that they need and give them an out for when that service is not needed without having to enter the Capacity Release race on a regular basis.  Another example may be where a shipper needs seasonal firm capacity but the pipeline doesn’t offer a program that meets their specific needs. In this case, the shipper could match up with another shipper that can handle the off-peak quantities and share the transportation obligation. There may even be credit advantages, though I may be stretching my imagination too far on that one.

So what does the FERC have to say about this?  In Order 809, there were very few specifics.  There were references to a number of pipelines already offering this capability and, via that reference, the FERC decided that the service requirement only applies to Firm transportation and implied that there would be an agent involved to manage the contractual relationship and pipeline interaction.

A pipeline could implement such that each shipper had nomination rights.  The pipeline could implement such that the agent is mandatory and the agent manages the different shippers.  In the example pipelines that I researched, it appeared that there was always an agent relationship and the agent was responsible for managing the transactions for the shippers. These pipelines implemented this service prior to Order 809.

Again, the FERC was silent on nominations, billing, quantity rights, and location rights in Order 809.  It did say that the financial responsibility was with both parties.  So, like Capacity Release, if the one party fails to perform, the second party is financially responsible.

If the pipeline implements this in the easiest way, with an agent, then the transaction datasets would be unaffected.  The only impact will be to be able to add two shippers and their separate terms onto one contract and to be able to post those separate terms in the Transactional Reporting requirements.

We have 75 days from the FERC issuance of Order 809 and then 60 days after a shipper issues a request for such a service.  The worst case scenario is that a pipeline would have to implement this on June 14th, 2015 – 75 days after Order 809 was issued. The best case is any 60 day period after June 14th.

Is this something where shippers can find value? Does it help producer services, electric generators or agents?  It will be interesting to see the filings for this requirement, in response to Order 809, and to see how many shippers utilize this offering.

by sylviamunson

Why compliance matters to non-regulated entities

I often hear people comment that compliance issues don’t apply to them because they are not a FERC-regulated company.  If you are involved in transportation at any point in the natural gas business then compliance issues matter to you.

You can see the reason when you refer to the old adage that ‘it all rolls downhill’ but there is more to it than that.

Look at some of the basic FERC regulations.

The Gas Day.  NAESB, hence FERC, says that the Gas Day is from 9:00 am – 9:00 AM Central Time for interstate pipelines.  If you are transporting on an interstate pipeline, you must work within this timeline.  What about if you are delivering onto this pipeline as an upstream interstate pipeline or a midstream operator? Then you must work within this timeline.  What about if you are an LDC or Utility receiving from the interstate? Same story – you must use the timeline.  Now, if you have to use the timeline to put gas onto or take gas off of the interstate, guess what? It’s best if you run your own operations on that timeline! So as a midstream operator or an LDC, the easiest answer is for you to match the gas day of the interstate that you connect with.

This same logic applies to the nomination cycles.  Your business may not need to use all of the nomination cycles, but if you interconnect to an interstate or nominate on an interstate then you have to comply with those cycles in some manner to confirm your gas. You may be able to run your business such that you only have one official cycle, such as the Timely cycle, but you still have to be aware of and confirm on the other cycles.

As a midstream operator, you may not need all of the upstream party and contract information because you know where the gas is coming from in your gathering system, but you will need the downstream party and contract information to be collected with nominations so that it can be provided in the confirmation process.

As an LDC, you may not need the downstream party and contract information because you know where the gas is going in your distribution system, but you will need the upstream side of the information for support of confirmations on your upstream interconnects.

And then there is customer service.  Customers who nominate gas on your system are often the same customers transacting with interstate pipelines.  The more that you use the same terms, deadlines, and processes, the easier the communication will be with your customers.

I believe that there is an opportunity in the NAESB process for nomination model types to be defined that are specific to the needs of the midstream and LDC businesses.  The current model types are close to what these business lines need, but they require too much information compared to the true business model of the upstream.  If a model type existed that supported gathering from many wells without including upstream information but required the interconnect documentation on the downstream side, it would be a golden tool.  If a model type existed that supported the distribution side of the business without all of the unused downstream information but required the corresponding upstream interconnect documentation, it could ease the burden of some of the transactions.

But it takes someone to lead the charge.

by sylviamunson

Welcome

It seems like this first posting should explain why I’m writing a blog for Contents Under Pressure. I have worked in the natural gas industry for more than 30 years.  Out of that fabulous experience, I have just completed a book, titled “Contents Under Pressure – The Complete Guide to Natural Gas Transportation”. This is the book you have been waiting for and it will be available in early September.

But that’s not all.

In my work in the industry I get a lot of questions. Sometimes they make me dig deep into history and research to find the answer. Sometimes I know the answer off the top of my head.  And the fun questions make me look at the way I think about the business in a whole new way.

This blog is for those fun questions.

Here we will cover things that make you think (I hope) about the way you look at the business. It will cover super detailed explanations of really nit-picky issues that come up again and again. And we’ll will talk about what is going on in the industry that affects our business – market happenings, FERC rulings, and such that could impact or have already impacted our business.

I hope you enjoy it.  I love working in the natural gas industry because it is constantly changing through government rulings, market shifts and technology advances.  If you like change, natural gas is a great place to work.

Sign up to receive emails as they are posted.  Follow me! Pre-Order my book so that you’ll be ‘in the know’.  Provide comments and questions so that this can be as beneficial to you and your gas industry career as you need it to be.

Sylvia