Market entry assurance is the process all new entrants must undergo to provide assurance to MOSL that their business capability is able to uphold market obligations.
Most applicants take between 40-60 business days to complete the Market Entry Assurance process, depending on whether they go through self-certification or enhanced certification.
There are two routes applicants can take to complete MEA; self-certification and enhanced. Applicants with small scale operations, mostly manual processes, and who intend to only use the Low Volume Interface (LVI) in CMOS can go through self-certification. This is considered the ‘light-touch’ route. All other applicants must go through the enhanced certification route, which involves providing more in-depth assurance to MOSL and undergoing testing of the company’s systems.
MEA provides MOSL and other Trading Parties with assurance that you can uphold your market obligations and ultimately participate in the market. It also fulfils two Trading Conditions.
MOSL does not charge applicants to undergo MEA.
Each MEA document will ask for different types of information, and will clearly explain what you are expected to provide. While supporting documents such as process maps or policies are not required, you can submit these if you feel they will help MOSL to better understand your company’s capability.
It is up to you who signs the documents, but it should be someone with authority to sign on behalf of your company.
MOSL has not specified the level of detail required, as it differs between applicants and depends on individual circumstances. We are happy to review drafts and answer questions before you submit final versions. Please contact MEAC@mosl.co.uk for more information.
Market Entry Assurance Testing (MEAT) involves two stages; Interface and Data Transaction Testing (IDTT) and Market Scenario Testing (MST). IDTT is designed to ensure your company’s systems can interact with the CMOS, whereas MST provides a series of business scenarios to ensure your systems can complete common system transactions. For more information on MEAT, see the MEAT plan.
Only applicants going through enhanced MEA need to do MEA Testing.
Yes, MOSL provides test data for new entrants who need to complete MEA Testing.
No. You only need to complete all scenarios if you plan to use all transactions in the High-Volume Interface (HVI). If you only plan to use the HVI for select transactions, you only need to complete scenarios in which these transactions feature.
We strongly encourage applicants to complete their MEA Testing within a 10-day window. However, if you are unable to complete testing within this timeframe, it can be extended.
If one of the BSA assurance statements is not applicable to your business, for example you are not offering accredited entity schemes, you do not need to complete the statement.
The third party report should cover your company’s approach to completing the Business Solution Assessment, and should assure the outcomes of the assurance undertaken. If you consider some statements to carry a higher level of risk, you may consider it appropriate for the third party report to provide assurance on these statements as well.
No. MOSL is a private company working on behalf of its water company members in the creation of the new competitive market for non-household water customers in England.
The gap site allocation process is outlined in CSD0005: direction to supply allocation process, which can be found on the codes page. Registering the supply point follows the same process as a new connection detailed in CSD 0101: Register SPID
Market re-assurance is the process by which a Trading Party provides assurance to MOSL that any material change(s) it has made to business capability does not affect its ability to uphold its market obligations. The market re-assurance process is similar to the MEA process,except that Trading Parties only need to complete the stages affected by the material change(s). For example, if a Trading Party is not changing the way it interfaces with the CMOS or how it sends and receives transactions, it will likely not need to undergo re-assurance testing.
It is usual for the sums on the reports to differ slightly. This is caused by rounding. For example, in the Aggregated Report all the relevant charges (from multiple Supply Points) are initially added without rounding. The totals are then rounded to four decimal places.
In the Disaggregated Reports the charges in each line are shown rounded to four decimal places. When these rounded numbers are added, there is a minor discrepancy in overall total.
No. The Tariff Report will contain tariffs from all wholesalers and will be available to all wholesalers and retailers.
The format and content of the Settlement Reports is defined in CSD0201: settlement timetable and reporting. Where defects in the deployed version of these reports have been identified, the reports will be amended to reflect CSD0201.
This is for the participant(s) to decide between them and is dependent on the requirements of both parties.
The answer to this varies depending on the organisation. Participants should carry out the appropriate checks in respect to the accuracy of the settlement calculation and of the data supplied, to suit the requirements of their organisation.
When a meter has no actual reads in the period, the Yearly Volume Estimate (YVE) is used to estimate charges.
When a Yearly Volume Estimate (YVE) of zero is supplied, zero settlement charge is calculated.
Following the distribution of the R2, R3, R4 and RF Settlement Reports and the distribution of the R1 Settlement Report, where the pre-payment option has been selected by the retailer based on the P1 report - the wholesaler will calculate the reconciliation balances and invoice the retailer in respect of these balances.
The reconciliation balances are the differences between the amounts already paid by the retailer for the invoice period, and the charges calculated by the updated Settlement Run. As such, reconciliation could result in either a refund or an additional charge being applied to the retailer.
With regards to disputes, the next Settlement Run will provide corrections to the disputed item(s). A wholesaler can then reconcile against the previous invoice with any over or under charge identified and reconciled. If this can’t be done, or the dispute meets certain conditions as detailed in Market Terms 4.13.4, then an unplanned Settlement Run can be requested.
Yes. P1 Settlement Reports will be provided to all wholesalers and retailers participating in the market.
Market participant’s systems will inevitably not be directly comparable to CMOS, which may result in this variation. For example, Participants may have various financial, billing and specialised sub-systems in place, which produce similar, but not directly comparable results. For example, is possible that a financial system may calculate monthly revenues, but the routines used to calculate consumption will not be the same as those in CMOS. A billing system is likely to produce bills from meter read to meter read, so these would not cover the same period as the CMOS settlement system. However, over a longer period, these effects will balance out.
Settlement Runs are done overnight, but will only include transactions up to the end of that business day (6pm).
The most likely cause of a user exception is when the tariff for a service component references a specific data item, which has not been provided for that supply point. An example of this could be a Surface Water Drainage (SWD) tariff which referenced Rateable Value (RV) when there was not an appropriate RV available.
Settlement is the process by which MOSL calculates the charges payable by individual retailers to their related wholesalers, for the supply of water and sewerage services. These are created for each invoice period (monthly).
Please note, MOSL takes no part in either the invoicing or funds transfer in respect to these charges. These should be dealt with directly by the wholesaler and retailer in accordance with Business Terms. For more information please the Section 4.13 of the Market Terms.
Participants may have seen a ‘system exception report’ during market testing. The objective of this report is to provide evidence to MOSL of an issue with settlement, primarily due to an internal CMOS defect.
The Central Market Operating System (CMOS) carries out detailed calculations on data maintained by market participants (MPs). The calculations of these are detailed in CSD0207: charge calculation, allocation and aggregation and make use of the tariff data maintained by the wholesalers in accordance with CSD0208: submission and validation of wholesaler tariff data. MOSL produces settlement reports, using this data, in accordance with CSD0201: settlement timetable and reporting. For upcoming settlement and report timings, please visit the MOSL calendar.
This is a report created by MOSL, in addition to those specified in the Market Terms and Code Subsiduary Documents (CSD). It flags up cases where there are ‘unexpected’ changes in settlement between different settlement runs.
P1 runs are carried out before the invoice period, whereas R1 runs are carried out immediately following the invoice period. In accordance with Section 9.2.2 of the Business Terms, a retailer can choose either a pre-payment or a post-payment option with agreement from the wholesaler, in order to pay its primary charges.
The most likely cause of incorrect settlement is incorrect or missing data. Your first action should be to carefully check the data inputted and your calculation.
If you’re still concerned the settlement is wrong, please fill out the Settlement Clarification Request Form.
R2, R3, R4 and RF settlement runs are carried out in a consecutive order every two, eight, fourteen and sixteen months after the end of the invoice period. Each run is a complete recalculation of the settlement charges and factors in new and updated data about each supply point, which has been submitted market participants into CMOS.
The next settlement run will have the corrections of the disputed item. The wholesaler can then reconcile against the previous invoice for any over/under charges. In the event that this cannot be done or where the dispute meets certain conditions, as detailed in Section 4.13.4 of the Market Terms, an unplanned settlement run may be requested.
The settlement system is working well. Settlement testing so far has produced accurate answers based on the calculations specified in CSD0207:charge calculation, allocation and aggregation. However, these answers may not be exactly the same as currently produced by participants’ own systems.
If you are the data owner, you can correct the data by sending in suitable transactions. Please note, there are some transactions which are currently unavailable. In some cases, it it is possible to use a workaround, as detailed in the workaround log, other times may be necessary to wait until a future CMOS Release to correct the data.
The Supply Point Identification (SPID) will stay the same regardless of the tariff applied for settlement, as it relates directly to the premise. If a meter is installed which moves the premise to measured then the wholesaler will need to update the market operator (MOSL) using the T104.W, with all the neccesary data to update this. Settlement charges are calculated on a daily basis and will take into account any changes to tariffs affecting data.
Non-market meters are typically household meters. Non-market meter information is required if there is a situation where they are needed to calculate volumes to a non-household premise.
A TCORR transaction is used to correct the data submitted through the standard, equivalent T transaction. For example, TCORR124.W will be used to correct the data submitted through T124.W; provided that at least one of the conditions in Section 2.5.2 of CSD0105:error rectification and retrospective amendments is not satisfied. If all the conditions in Section 2.5.2 of CSD0105 are satisfied, then the standard T124.W can be used to make the neccesary changes.
As a field trough is ordinarily associated with a farm or other associated property, the expectation is that the ‘address’ of the field trough should be that of the property. As such, as full an address as possible should be provided with the relevant postcode having at least the OUTCODE portion. This is defined in CSD0301:data catalogue (D5009:postcode), which states the postcode must be provided to Outward code level as a minimum.
The Market Performance Framework is a set of mechanisms which are designed to govern, incentivise, monitor and enforce compliance with market standards. For more information on the processes which comprise the Market Performance Framework, please see CSD0002:market performance framework.
Market performance standards are a comprehensive list of success criteria participants need to achieve to operate in the market. For more information on the market performance standards and the success criteria for each standard, please see Section 3 of CSD0002:market performance framework.
For each market performance standard, there is an associated charge for non-compliance. Market participants will incur associated charges each month based on their performance. For more information on the market performance standards and the methodology for calculating the charges, please see Section 3 of CSD0002: market performance framework.
Three different performance reports are produced for each market participant:
a) SPID Data related Reports
b) Meter Reads related Reports
c) Monthly Market Performance Standards Reports
The performance reports provide market participants with information about how they are performing in relation to the market performance standards.
The market performance standard charges report is also produced for each market participant and summarises the charges they have incurred during each month. For more information on the details contained in each report, please see CSD0002: market performance framework.
The market performance reports have been published since October 2016, however, market participants are not required to pay the charges until 12 months after 'go-live'.
The MOSL Service Desk can be contacted by telephone or email between the hours of 0800 and 1800, Monday to Friday. Calls made out of hours will receive an ‘out of hours’ message and the call will be terminated. Emails received out of hours will be processed on the next working day.
Only authorised individuals can contact the Service Desk. If you’re unsure who the authorised users are for your organisation, please check with your Portfolio Managers who have access to the list of authorised users.
The Service Desk agent will validate your identity by using your email address, telephone number and work address to check. They will then ask a few questions with regards to your call to make sure that the Service Desk is the right option for your issue (you will be advised who to contact if not). They will then take details of the problem and issue you with a reference number.
When an email is sent, the Service Desk agent who receives it will validate that your email address is registered as an authorised contact and will add your issue/email content to a ticket. A response will be sent with a ticket reference number.
If you are not an authorised user, you will receive a reply advising you of this.
When contacting the Service Desk, please be as clear as possible when describing the problem you’re facing. If you’re reporting what you believe to be a defect, the more information you provide, the better Service Desk can assist. Please supply as much of the following information as you can, including:
· Date and time of the issue – this helps to find an event in the database
· Type and version of the browser used
· Version of the system used (the release version is shown on each Portal screen)
· A description of the problem
· What you were trying to do – i.e. your requirement
· A summary of why your requirement hasn’t been met
· Step by step instructions on how to recreate the issue (so Service Desk can get a better understanding of it)
Any relevant data that was used:
· User Name, Organisation ID
· SPID, Meter, DPID etc.
· Meter Serial Number, Effective Date, Meter Type, Read Type, Supply Status
Evidence to support the issue:
· XML (for both Portal and B2B – input and return files where applicable)
Once a ticket has been logged, the Service Desk will assign it to the UK Project Team, which will run a daily triage session to categorise each ticket and assign a resolver through one of the following:
· New Defects
· Test Partner Data Issues
· Data Partner Queries
· Market Services
· CGI Project Team (UK/NL)
You should contact the Service Desk if:
You are having problems connecting to the MPS environment after receiving your user credentials
The activities you’re conducting in the member participant ‘sandpit’ (MPS) (either the B2B interface or Portal) are not producing results as specified in the XSDs or Codes
If the activity is part of released functionality
If the issue isn’t part of the published defect list
If you are a UAT volunteer, any issues found when conducting a UAT test scenario in the UAT environment should be reported to the MOSL Test Partner.
If the potential defect has been located in the MPS environment, this should be reported to the MOSL Service Desk. Only issues found when executing user acceptance test (UAT) tests in the UAT environment should be reported to the Test Partner.
Retailers will own the relationship with the customer in the open market, however the Operational Terms set out how contact and information should flow between Wholesalers, Retailers and customers.
Please see the Operational Terms on the Codes page for further information.
MOSL holds regular meetings, teleconferences and events. For information on MOSL's upcoming events please visit the MOSL Calendar.
Whenever an incident record is closed by the Service Desk because a defect has been raised on ALM, the defect number is clearly noted in the remedy work update and in the resolution notes. You should therefore be able to check the defect number in the resolution notification and on the remedy portal.
Changes to the Market Codes can be raised by Trading Parties, the Market Operator (MOSL), the Panel and the Authority, by raising raising a Change Proposal. Please visit the Change Proposal Forum on the Change page for more information.
The Panel works with the Market Operator to deliver strategic governance of the market. The Panel's role is to ensure th Codes’ operation and evolution to facilitate efficient and effective market outcomes. For information on the role, functions and Panel members please visit the Panel page.
The Trading Dispute process is used to rectify any data item errors, resulting in incorrect Primary charges being invoiced on the Settlement Report. The sole purpose of the process is to correct errors and is not to assign liability to any parties involved.
Trading Disputes occur when two Trading Parties disagree on whether a data item has been accurately maintained, which has an effect on Primary Charges. Under the Market Arrangements Code (MAC), parties have an obligation to ensure that data is maintained accurately. In the event that an inaccuracy occurs, raising a Trading Dispute is a method of escalation to ensure rectification. However, prior to raising a Trading Dispute, a Trading Party must make all reasonable endeavours to resolve the discrepancy with the parties involved.Trading Disputes are assessed against key criteria which must be met in order for the Trading Dispute to be heard by the Trading Dispute Committee, which will decide the outcome of the dispute. Trading Disputes details are confidential, although summaries will be published on the portal.
A Trading Disputeis valid when it meets the following criteria:
• The Trading Parties are disputing a data item
• The Disputing Party must have notified the other Disputing Party(ies) in writing of the dispute and held a meeting to try and resolve the dispute
• The Trading Dispute should not be in respect of Non-Primary Charges, which are outside of MOSL’s remit
• The same data item/error has not been previously investigated
Trading Disputes should be raised and managed through Kissflow. Any additional information that the Trading Party believes would strengthen their cause for raising a Dispute can also be attached to the application. MOSL will acknowledge the application within 5 Business Days.
This depends on the specific Trading Dispute, but the general process is as follows:
1. Raising the Trading Dispute
2. Hold resolution meeting with disputing parties
3. Raise to Trading Disputes Committee for a decision
4. Refer to arbitration
Prior to escalating a Trading Dispute to the Trading Disputes Committee for resolution, Trading Parties must first have:
• Notified the other Disputing Party(ies) in writing of the existence and subject matter of the Dispute; and,
• Held a meeting of each of the Disputing Parties to try and resolve the dispute.
Additionally, MOSL will accept additional relevant information from impacted parties.
MOSL will take one of the following steps:
• Undertake the next Planned Settlement Run after the 20 Business Days the parties have to refer the dispute to arbitration;
• Where there is no further Planned Settlement Run, undertake a Dispute Settlement Run;
• Where the period to the next Planned Settlement Run (considered together with the materiality of the Trading Dispute) is such that the Trading Disputes Committee believes that a Dispute Settlement Run is justified, undertake a Dispute Settlement Run; or
• Where a Trading Dispute is not decided until after the relevant final Settlement Run to take no further action.
Fees for any such rectification will be assigned across the Disputing Parties as per the responsibility assigned by the Trading Dispute Committee.
If you are unhappy with the decision proposed at the Trading Dispute Committee meeting, you can refer the Trading Dispute to arbitration within 20 Business Days from the Trading Dispute committee decision being made.
If a Trading Dispute is not referred to arbitration within 20 Business Days, then the decision of the Trading Disputes Committee wiil be final and each Trading Party must comply.
MOSL do not play an active role beyond monitoring within the Arbitration process once the Dispute has been escalated. Responsibility remains solely on the Trading Party to organise, communicate to MOSL, and undergo the Arbitration Process, which must be raised under London Court of International Arbitration rules.
For more information on the a Trading Party’s obligations during the Arbitration process, please read Section 19 of the Business Terms.
A retailer may ask the wholesaler to take a read on a non-market meter if required for a transfer by following process B11 in the operational terms.
If the T104 has been sent on an incorrect supply point, it can be "erased" through a TCORR174. A T104 can then be sent on the correct supply point
Customers should be directed to their retailer who will arrange for the meter removal.
In exceptional circumstances, if an accurate read cannot be obtained because of a faulty or absent meter, the final read submitted should be the last valid read obtained (and sent as Visual Meter Read Type) and the Wholesaler should send through a volumetric adjustment via a T138.W.
This will differ according to wholesaler, all non-primary charges must be detailed on the wholesaler's tariff document published on their websites.
This could be because the request was sent outside the cancellation window or other data is invalid. This should be corrected and resent. If it is too late to send a cancellation then an erroneous transfer request must be sent after the switch completes.
Both retailers may cancel a switch for different reasons, these are detailed in CSD 0103
Once an erroneous transfer has been completed the SPID any relevant data changes will need to be resubmitted by trading parties.
Yes, a customer may provide a transfer reading to their new retailer, the retailer should submit this to CMOS. More information on transfer reads can be found in CSD 0102 and CSD 0202.
Yes, the wholesaler received the T108.M advising that the SPID is changing retailer.
All relevant parties can request a meter accuracy test, a request may also come from the Trading Disputes Committee.
The wholesaler is responsible for updating CMOS with a change of meter, this can either be done through a T117 or by removing the old meter and submitting new meter details. CSD 0104 details when each is appropriate.
All building water is in the new market, once construction has finished to the new property that will not be in the market then the supply point can be deregistered.
The minimum frequency for submitting cyclic reads is set out in CSD 0202: meter read submission: process, however, retailers are not prohibited from submitting more frequent reads than this.
Wholesalers read and submit reads as required on non-market meters.
A re-read must contain exactly the same data as the original rejected read, if anything has been amended it should just be submited as a normal read.
No, cyclic reads are gathered when a meter has been read hence they cannot be estimated, the valid meter read methods for all reads can be found in CSD 0202
Transfer reads can be submitted from 2 days before the registration start date to up to 5 days after the registration start date depending on the read type. This is discussed in more detail in CSD 0102.
Developers should continue to speak to the relevant wholesaler and follow their existing processes. Retailers should also direct queries to the relevant wholesaler.
The wholesaler should submit volumetric adjustments within 2 BDs of the allowance being determined.
The valid data set is in CSD 0301, adjustments will typically be made if the meter is not recording consumption accurately, there has been a leak\burst or has been used for firefighting.
Wholesalers maintain this data and if it needs to be changed\corrected, after updating CMOS the notification will go to the retailers who will need to adjust their customer billing.
This will vary according to wholesaler, however these are all published on wholesalers tariff documents and should be agreed before the necessary work commences.
The wholesaler is responsible for updating the supply point with the disconnection data including reads. If the work was done by an accredited entity the information is still passed to the wholesaler to make the relevant changes.
Depending on the type of information that needs to be changed, certain data corrections can be performed on CMOS however they will typically involve agreement between trading parties. CSD 0105 covers the processes for this.
No, the relevant wholesaler should be contacted to confirm this, however it will be published on their website. Wholesalers' obligations in this regard are governed by their Instrument of Appointments.
If you are making a material change(s) to your business capability, which affects the way in which you uphold your obligations, you should consider whether you need to undergo Market Re-assurance. The decision as to whether it's needed, and which stages are required, is decided by Trading Parties rather than MOSL.
Material changes are any changes made by a Trading Party which affect the way they uphold their market obligations. The below table provides guidance on what events may trigger Market Re-assurance, and the subsequent steps in the process.
The Market Re-assurance process is similar to that of MEA, in that it provides assurance on the business capability to be used in the market. However, when completing re-assurance Trading Parties do not necessarily need to complete all stages like they would in MEA. There is also no Trading Application to complete and the Market Re-assurance Information Return replaces the Applicant Information Return.
Market Re-assurance will involve completion of the Market Re-assurance Information Return, which sets out how the material change(s) made affect the business capability and the Market Re-assurance Plan, which sets out the timeframe for the rest of the re-assurance process. Depending on the nature of the material change(s), and the MEA route the Trading Party underwent, market re-assurance can also involve a Self-certification declaration, Business Solution Assessment (BSA), and/or Market Re-assurance Testing.
Re-assurance testing includes Interface and Data Transaction Testing (IDTT) and Market Scenario Testing (MST). All Trading Parties undergoing Re-assurance Testing need to complete IDTT. However, Trading Parties will only need to complete the scenarios within MST which are affected by the material change(s) for which they are undergoing Market Re-assurance.
Trading Parties completing enhanced Market Re-assurance will likely be required to complete a Business Solution Assessment (BSA). You do not need to complete all the assurance statements, but should complete the approach and risk consideration sections and provide a third party report. You will only need to complete the assurance statements which are affected by the material change(s) for which you are undergoing re-assurance. All other statements can be market as ‘N/A’.