Formbay

Published name

Formbay

Please provide any comments in relation to these provisions (clauses 1-6).

Clause 5. Noting that automated verification and audit services developed by Formbay over 14 years of SRES operations should be considered in order to reduce the burden on manual audits while taking advantage of additional benefits including automated measurements, risk identification, product verification.
Clause 6. Formbay gathers evidence and generates audit packs in the VEU as well as the SRES schemes and would advocate for harmonisation across these schemes.

Please provide any comments in relation to these provisions.

Clause 7. Recommend explicit provisions to allow authorised agents/platforms (like Formbay) to submit applications on behalf of clients, provided adequate consent and audit trails exist.

Please provide any comments in relation to these provisions.

NA

Please provide any comments in relation to these provisions.

11. SPV-like systems could validate elements (e.g. component-level metadata, site ownership, electricity inputs.
12. FormBay’s system expertise can help structure this modularity (e.g. via digital configuration templates.
13. Retailer-integrated platforms (like FormBay could offer) to streamline data intake and reconciliation.

To reduce duplication leverage data from other schemes (e.g. RET, NGER, SPV) rather than requiring fresh submission.

Please provide any comments in relation to these provisions.

Clause 20.
The rules should explicitly recognise the role of registered agents and digital platforms that support producers in creating profiles and certificates. These intermediaries should be able to act on behalf of clients via consent-based delegation.

Where metering data is required (e.g. for electricity use in Clause 20), the rules should allow agents to access such data via third-party integration or API access with the customer’s consent.

For distributed or small-scale producers without metering infrastructure, a verified estimation method using approved metadata inputs and sampling audits should be permitted, similar to SPV and STC deeming models.

Allow platform operators to submit profile applications, request certificate registration, and manage compliance workflows on behalf of registered persons, using secure identity and delegation processes.

Clause 21.

The rules should explicitly allow delivery profile holders to delegate the addition of post-production information to a trusted agent or platform (such as Formbay), with proper consent and evidence controls.

To support scalability and reduce administrative burden, we recommend that standardised, pre-approved delivery module templates be developed (e.g. certified pipeline segments, storage tanks, shipping routes), which can be referenced across multiple deliveries.

The GO Scheme should support API-based integration for REGO certificate retirement and electricity usage data from third-party systems (e.g. DNSPs, retailers, metering agents), especially where the delivery party does not hold certificates directly.

Where real-time post-production data is not immediately available, a provision should exist for temporary placeholder values, with final values to be submitted within a defined reconciliation window (e.g. 60 days).

Please provide any comments in relation to these provisions.

Clause 22.

To reduce friction and improve consistency, the rules should provide a standard evidence matrix for common scenarios (e.g. on-site use, export, shared infrastructure), and allow evidence to be submitted via a trusted agent or compliance platform.

We recommend that the GO Register support automated validation of related certificates (e.g. REGO, STC, LGC), using APIs or structured ID lookups, so platforms can ensure proper linking at scale.

To support exports and international compliance, the rules should define standardised schemas for additional certificate attributes (e.g. hourly timestamping, zero-carbon transport, First Nations content), and provide public templates for participants to follow.

We suggest enabling optional pre-validation or draft review of certificates (prior to full registration), especially where the production and delivery data is complex. This would support early engagement and reduce rejection risk.

Clause 23.

Enable Agent-Mediated Consumption Reporting
The rules should explicitly allow delegated agents or digital compliance platforms (such as Formbay) to act on behalf of the consumption profile holder to submit consumption information. This is critical in retail and aggregator models where the certificate holder may not have the capability to interface directly with the registry or consolidate evidence from distributed consumption endpoints.

Clarify Evidence Requirements and Allow for Standardised Consumption Declarations
The rule requires evidence that the product could reasonably pass from delivery gate to the point of consumption, and that the product was used after arrival. We recommend providing clear, standardised templates or declarations (e.g. for common scenarios such as industrial gas use, electricity co-location, or pipeline delivery) to streamline compliance and reduce administrative burden.

Support Grouped or Aggregated End Use
Particularly in network or retail scenarios (e.g. hydrogen or renewable gas delivered via pipelines), the certificate may apply to multiple consumption sites or customers. We recommend confirming that Clause 23 supports consumption declarations based on aggregate retail sales, with proportionate attribution to a group of consumers, similar to current GreenPower and retailer-led LGC models.

Related Certificate Cross-Validation
We support the requirement to assess whether related certificates (e.g. from other schemes) conflict with the PGO certificate. However, we recommend the Regulator implement automated conflict-checking tools or APIs to assist platforms like FormBay in flagging mismatches early in the submission process.

Timing and Grace Periods
In some cases, final consumption information (e.g. volume used, timing, buyer details) may only be confirmed after delivery. We recommend allowing a reasonable window (e.g. 60–90 days) for post-delivery submission of consumption data, provided it is auditable.

These changes will ensure Clause 23 supports real-world use cases where consumption is managed through retail contracts, shared infrastructure, or by third-party compliance platforms.

Please provide any comments in relation to these provisions.

Clause 24.

Support for Agent-Managed ARC Workflows
The rules should explicitly allow delegated agents or compliance platforms (such as Formbay) to manage ARC workflows on behalf of registered persons. This includes receiving the activity statement, collating supporting evidence, and submitting the required declaration — provided there is auditable authorisation. This is essential for participants who rely on third-party systems to manage GO compliance.

Clarity on Scope of Included Activity
We recommend that the rules and supporting guidance clearly specify:

Whether the activity statement includes only registered certificates, or also created but unregistered certificates.

How transferred profiles and related historical activity are handled across multiple holders.

How inactive profiles or suspended profiles are reflected (if at all).

Clear delineation will ensure participants understand their obligations and can prepare appropriate documentation.

Digital Record Formats and API Access
To support automated compliance workflows, we recommend that the PGO certificate activity statement be made available in machine-readable format (e.g. JSON, CSV), and accessible via API. This would allow Formbay to pre-check client declarations and automatically generate supporting documentation, reducing administrative burden and risk of non-compliance.

Integration with Other Scheme Reporting
Where data overlaps with RET, STC, or NGER reporting (e.g. facility identifiers, production volumes, emissions), we recommend enabling data sharing between the CER and the GO Regulator, or allowing the ARC process to reference existing validated reports. This reduces duplication and improves consistency across schemes.

Support for Split-Year Transfers
Where a profile is transferred during the financial year, the new holder may not be able to verify data recorded prior to transfer. We recommend that:

The Regulator include split-declaration logic, allowing the prior holder to verify the earlier portion, and

Agents (like Formbay) be allowed to coordinate compliance submissions on behalf of both parties, if authorised.

These refinements will ensure Clause 24 delivers its intended integrity outcomes without introducing friction or duplication — particularly for high-volume participants or those using compliance platforms.

Clause 25

Support Correction Delegation to Agents/Platforms
The rules should clarify that a nominated agent or compliance platform (such as Formbay) may prepare and submit correction declarations and supporting evidence on behalf of the registered person, provided proper authorisation exists. This ensures that businesses with limited internal compliance capacity are not disadvantaged and that corrections can be efficiently handled at scale.

Implement a Digital Correction Interface
Corrections should be supported by a structured, digital interface (API or form-based), rather than ad hoc submission of PDFs or emails. This enables platforms like Formbay to:

Flag likely certificate errors before the ARC deadline,

Automate correction submissions, and

Reduce back-and-forth with the Regulator.

Allow Linked or Cascading Corrections
Where an upstream certificate correction triggers errors in related (downstream) certificates, the Regulator should allow batch or cascading corrections to be initiated within a defined reconciliation window. This supports traceability and system integrity without requiring participants to restart entire certificate chains.

Please provide any comments in relation to these provisions.

Clause 26

Support for Consequential (Cascading) Corrections Across Related Certificates:
Clause 26 rightly recognises that a correction to one certificate may require adjustments to downstream certificates that reference it. We recommend that the rules:

Formally support batch or cascading corrections triggered by a single upstream correction.

Allow authorised agents (e.g. Formbay) to submit linked correction sets in a single action.

Minimise the risk of data mismatch by enabling pre-checks or warnings in the registry system.

This ensures systemic integrity without introducing excessive manual overhead.

Enable Agent or Platform-Initiated Corrections:
Where a registered person has delegated compliance responsibilities to an agent or platform (such as Formbay), the rules should confirm that:

The agent can prepare and submit correction requests on behalf of the certificate holder.

The Regulator can accept these corrections with proper authorisation and audit trail.

Digital Correction Interface with Structured Inputs:
We recommend that the Regulator implement a structured digital interface (e.g. portal forms or APIs) for certificate corrections, rather than ad hoc uploads. This should:

Include standard correction categories (e.g. batch volume, emissions intensity, attribute errors).

Allow batch uploads for multiple certificates with similar issues (e.g. formatting errors or missing delivery data).

Provide real-time feedback to platforms like Formbay on correction status.

Clarify Timing and Priority of Corrections:
We suggest that the Regulator:

Define cut-off dates for pre-declaration corrections (e.g. 7–14 days before ARC deadline) to ensure efficient processing.

Prioritise corrections that prevent downstream invalidations or affect international claims (e.g. for export attributes).

Clarify if there is a limit to how many times a certificate can be corrected before it must be invalidated.

Clause 27.

Clause 27(1)(a) allows the current production profile holder to request invalidation. We recommend explicitly extending this to authorised agents or compliance platforms (such as Formbay) who manage certificate workflows on behalf of clients. This enables proactive clean-up of certificates where clients exit the scheme, change business models, or consolidate portfolios.

Do you have any additional feedback in relation to PGO rules (Parts 1-3 of the exposure draft) discussed in the consultation paper that you haven’t already provided?

No

Please provide any comments in relation to these provisions.

Clause 28.

We recommend the Regulator:

Provide clear guidance on how mixed-input systems are treated (e.g. proportionate eligibility),

Specify the data and measurement requirements for such systems to claim REGO certificates, and

Confirm whether STC-eligible systems (e.g. small-scale solar <100kW) can contribute to REGO creation during or after their deeming period.

Formbay could play a key role in verifying these claims if the system boundaries and eligibility logic are well defined.

Enable Pre-Check API or Validation Tool for Energy Source Eligibility
To support scalable and accurate REGO facility registration and certificate creation, we recommend that the Regulator provide a pre-check tool or API endpoint that allows agents and platforms to verify:

Whether a proposed energy source is eligible,

Whether a proposed facility type (e.g. tidal, waste-to-energy) is supported, and

What evidence will be required to demonstrate eligibility.

This will reduce registration friction and ensure integrity from the outset.

Please provide any comments in relation to these provisions.

Clause 30: Accredited Power Station Application
Support Streamlined Process for Existing CER-Accredited Assets
We support the use of existing accreditation data from the RET (e.g. LGC-accredited power stations) to streamline REGO facility registration. This minimises duplication and improves consistency. However, we recommend:

The Regulator enable automated data sharing with the Clean Energy Regulator (CER) to pre-fill or cross-check applications.

Applicants (or their agents) should be able to view and validate RET-linked facility data through the GO portal or API prior to submission.

Clarify Delegation for Applications by Non-Nominated Persons
Clause 30 allows a registered person other than the RET-nominated person to apply with consent. This should be extended to authorised agents/platforms (e.g. Formbay) acting on behalf of either party, with proper digital authorisation, to reduce complexity for large portfolio owners.

Clause 31: Other Facility Application
Clause 31 introduces the requirements for registration of non-accredited facilities — which could include small-scale solar, batteries, or new generation systems.

Clearly Define and Enable Small-Scale Facility Participation
FormBay recommends the rules clearly define the eligibility pathway for:

Small-scale solar systems (<100 kW) that are not RET-accredited but could become REGO-eligible after STC deeming expires.

Embedded generation behind commercial/industrial meters.

Community-scale assets not currently covered under RET.

This is especially relevant for FormBay’s installer-linked platform model, where SPV-like validation could help streamline data intake.

Delegate Application to Registered Agents or Platforms
The clause should explicitly allow delegated agents or digital compliance platforms (such as FormBay) to submit facility applications on behalf of owners or operators, with audit trail and secure authorisation. This is critical for:

Retailers or aggregators managing many customer systems,

Operators of embedded networks or community energy hubs, and

Industry partners managing REGO pathways on behalf of small generators.

Support Modular or Pooled Facility Applications
The current clause assumes a single facility = one system. We recommend enabling:

Modular registration where multiple co-located systems (e.g. solar, battery, EV chargers) are registered under one application.

Pooled applications for standardised system types (e.g. identical commercial rooftop systems across a portfolio).

This is especially relevant for FormBay’s role in enabling platform-level visibility and compliance tracking across many small or medium sites.

Digital Evidence and Component Registry
Clause 31 references component ownership and shared assets. We recommend:

A centralised component registry or template system that allows repeat use of validated component data (e.g. meter models, inverter types).

Support for uploading evidence (e.g. install certificates, SPV photos) via structured digital interfaces or APIs.

FormBay can assist in building, validating, or integrating with this system.

Clarify Eligibility for Systems with Shared Infrastructure
Many distributed systems share:

Grid connection points (e.g. embedded networks),

Infrastructure (e.g. batteries, load meters), or

Control systems (e.g. virtual power plants).

We recommend clarifying that such systems can be registered as a single facility or through an aggregated systems framework, and that guidance on boundaries and metering be published early. (This is particularly relevant for upcoming Clause 33 and aggregated systems.)

Do you have any feedback on the further policy considerations for REGO outlined in the consultation paper?

No

Do you have any additional feedback in relation to REGO rules or policy considerations discussed in the consultation paper that you haven’t already provided?

No

Would you like to upload a document?

No