9
Review Group 221: Security provision timing options and other supporting info

Review Group 221: Security provision timing options and other supporting info

Embed Size (px)

Citation preview

Page 1: Review Group 221: Security provision timing options and other supporting info

Review Group 221: Security provision timing options and other supporting info

Page 2: Review Group 221: Security provision timing options and other supporting info

2

Security Provision Timing Options

Sept

Option 1 -Security Provided

pre auction

Aug

QSECAuction

held

Allocation processstarts - after last

bid window

Option 3 - Securityprovided after

allocation

Max 18 days

Allocation processfinalised

Max 60 days

Oct Nov Dec

30 days?

Jan

Min 30 days

Option 2. Securityprovided prior to

allocationAdditional 15days requiredfor allocation

proccess

Variations

Option 4 - (hybrid of option 1 + 2) - minimum level of security or bid bond provided pre auction and security topped up prior to allocation

Option 5 - (hybrid of 1 + 3) minimum level of security or bid bond provided pre auction and security topped up after allocation has been finalised

Page 3: Review Group 221: Security provision timing options and other supporting info

3

Option 1 - Security put in place pre auction

Option 1 - Security put in place pre auction.

Security based on estimate of the Allocated Capacity Value (ACV)

Security required 1 month prior to the QSEC auction bid window starting but Users can top up security prior to the allocation process starting..

Pros Cons

Ensures Users do not participate in the auction

without security/commitment being in place

Requires User to estimate security required, which

could lead to errors if bidding strategy is

changed/flawed.

Ensures security is in place for all capacity

holdings protecting community from the full impact

of a User default.

Above could lead to Users providing head

room/more security than required, increasing

operating costs

Limited impact on current auction process and no

need to re-run auction

Possible barrier to entry due to project sanctioning

issues

Provides flexibility – Users are able to top up

security

Page 4: Review Group 221: Security provision timing options and other supporting info

4

Option 2 - Security provided prior to allocation process starting

Option 2 - security provided prior to allocation process starting.

Existing 60 day allocation window would be extended to [75 days] to allow the User to provide their security within 15 days of the auction bids being processed/prior to the allocation process commencing.

All new capacity bids will be removed if insufficient security is in place prior to the allocation process commencing.

Pros Cons

Allows User to provide security to match his

allocated capacity holding, reducing operating costs

Requires extension of allocation window.

Ensures security is in place for all capacity holdings

protecting community from the full impact of a User

default.

Potential minor impact on the timing of other

capacity auctions/processes.

No need to re-run auction

Page 5: Review Group 221: Security provision timing options and other supporting info

5

Option 4 - Hybrid of option 1 & 2.

Hybrid Option 1 & 2 - Security (minimum %) or bid bond (fixed deposit for all) put in place pre auction but Users allowed to top up prior to allocation

Security/bid bond required 1 month prior to the QSEC auction bid window starting but Users can provide their overall security within 15 days of the auction bids being processed/prior to the allocation process commencing.

Pros Cons

Ensures Users do not participate in the auction

without some security/commitment being in

place.

May requires User to still estimate security

required (if amount depends on a % of security).

Ensures security is in place for all capacity

holdings, protecting community from the full

impact of a User default.

Requires extension of allocation window.

Provides flexibility – Users are able to top up

security to exact amount required.

Page 6: Review Group 221: Security provision timing options and other supporting info

6

Option 3 – security provided after allocation

Option 3 Security is provided within one month of the allocation process taking place.

User provides their security within [30] days of the allocation process finishing.

Pros Cons

This option has the benefit of the User knowing

exactly what security is required.

User may fail to provide the security and the

auction may need to be re-run..

Allows for sufficient time for the security to be put

in place.

Re-running an auction would affect other QSEC

auction participants, incur costs, impact on

investment lead times and may impact on the

timing of other capacity auctions/processes.

Page 7: Review Group 221: Security provision timing options and other supporting info

7

Option 5 - Hybrid of options 1 & 3

Option 5 - Hybrid of option 1 & 3 - Security (minimum %) or bid bond (fixed deposit for all) put in

place pre auction but Users allowed to top up prior to allocation

Some security/bid bond required 1 month prior to the QSEC auction bid window starting but Users can provide their security within 30 days of the allocation process finishing

Pros Cons

Ensures Users do not participate in the

auction without some

security/commitment being in place.

May require User to still estimate security required.

Security in place is lower and will not

protect community from the impact of a

User default.

User may fail to provide all the security and the auction may

need to be re-run.

Provides flexibility – Users are able to

top up security to exact amount

required.

Re-running an auction would affect other QSEC auction

participants, incur costs, impact on investment lead times and

may impact on the timing of other capacity auctions/processes.

However amount obtained may be sufficient to cover the costs

of re-running the auction.

Page 8: Review Group 221: Security provision timing options and other supporting info

8

Security Required

Security Required against Scaling Factor

£0.0

£5.0

£10.0

£15.0

£20.0

£25.0

£30.0

£35.0

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

Approximate Scaling Factor across all ASEPs(User Credit Risk + Average User Project Risk)

Se

cu

rity

(£M

)

Total Security Required = £96.5M

Users with Assumed BB-Credit Rating

Note: overall amount of security is lower than previously reported due to changes to UPR and progress of projects affected

Page 9: Review Group 221: Security provision timing options and other supporting info

9

Bid bond level

Security to be provided (range) Number of Users

Over £1m 20

£0.5m to £1m 4

£0.2m to £0.5m 6

£0.1m to £0.2m 4

£0.05m to £0.1m 3

£0 to £0.05 4

£0 11

Large User level?

Small User level?