Every trading desk, utility, and generator reads their REC book differently. But almost every team is reading it the same way: log into M-RETS, log into PJM-GATS, open a spreadsheet, paste, reconcile, repeat. The tools haven't changed. The markets have.
Quick Answer: Solas is Innovo's REC operations platform that aggregates inventory across M-RETS (Midwest Renewable Energy Tracking System), WREGIS (Western Renewable Energy Generation Information System), NEPOOL GIS (New England Power Pool Generation Information System), PJM-GATS (PJM Generation Attribute Tracking System), and Evident into a single configurable view. Users connect existing registry accounts, build inventory views around the columns and metadata their team actually uses, tag certificates for allocation and compliance tracking, and execute transfers and retirements without leaving the platform. Every action is logged in task history, creating a timestamped audit trail for GHG Protocol Scope 2, RE100, and RPS filings. The platform is API-first: every UI action is also available via API, using one integration regardless of which registry is involved.
How do you connect registry accounts to Solas?
Connecting a registry account takes minutes and uses the credentials your team already has. Solas supports direct integrations with M-RETS, WREGIS, NEPOOL GIS, PJM-GATS, and Evident. Once connected, all sub-accounts and facilities associated with those credentials pull into the platform automatically.
You don't create new accounts. You don't transfer ownership. Your existing registry relationships stay intact. Solas reads your position and routes actions through the same access rights your team already holds.
For organizations managing inventory across multiple registries, multiple sub-accounts, or multiple organizational entities, everything lands in one table. The login rotation that introduces manual error disappears.
How does the Solas API work?
Solas is built API-first. Every operation available in the UI, from pulling inventory, executing transfers, retiring certificates, to applying tags, is accessible via the Solas API using the same endpoints, the same parameters, and the same logic.
The key difference from connecting to registries directly: one integration covers all of them. Whether a certificate lives in M-RETS, WREGIS, NEPOOL GIS, PJM-GATS, or Evident, the API call is identical. The registry is a parameter, not a separate integration. Teams that would otherwise maintain five different registry connections write one instead.
For organizations that want to surface Solas data within their own systems, Solas supports embedded views via a proxy setup, so operations can be conducted from within a third-party application without users leaving that environment.
API access includes both production and sandbox environments. API keys and full documentation are available within the Developer Portal once onboarded.
How do you customize your REC inventory view?
Solas shows every connected certificate in a single inventory table. The default view surfaces standard registry fields: registry, facility, fuel type, vintage, state, and volume. What you build from there is up to each user.
One of the core problems with managing inventory across registries separately is that each registry structures its data differently. Solas normalizes that data into a consistent model, so attributes like RPS eligibility, tier and class designations, and vintage are presented identically regardless of which registry the certificate came from. Reorder columns to match how your team reads a book. Hide fields that don't apply to your workflow. Each user saves their own view without affecting others.
The data doesn't change. The workflows around it do.
This matters most in organizations where multiple roles are working the same inventory. A compliance analyst running an RPS carve-out needs different columns front and center than a trader managing a short position. One inventory. Configured to how each person operates.
Comparison
| Standard registry export | Solas inventory view |
|---|---|
| Cross-registry aggregation | None (separate logins required) / M-RETS, WREGIS, NEPOOL GIS, PJM-GATS, Evident in one table |
| Data normalization | Each registry uses different field names and structures / Standardized model across all registries |
| RPS eligibility tracking | Registry-specific, not portable / Normalized and filterable across registries |
| Tier/class and vintage | Inconsistent labeling across registries / Consistent in every row |
| User-level customization | None / Column order, approval policies, saved views per user |
How do you use tags to allocate and organize inventory?
Tags are how you layer your organizational logic on top of the registry data. A certificate in M-RETS doesn't know it's earmarked for Illinois RPS obligation or allocated to a specific corporate buyer. Tags make that assignment visible, trackable, and exportable inside Solas.
You can create tags for any allocation need: compliance year, program type, RPS carve-out category, counterparty name, contract ID, or internal cost center. Tags apply at the certificate or batch level and carry through to reporting exports. The platform shows you how many MWh worth of certificates are within each tag, so you always know what's earmarked and what's available.
Common applications:
- Flagging certificates for specific state RPS eligibility carve-outs, including tier and class requirements
- Allocating inventory to a named buyer or offtake agreement before transfer
- Marking certificates as reserved or staged for retirement
- Organizing multi-vintage positions by procurement tranche
Tags don't alter the underlying certificate or the registry record. They impose your operational structure on the data without changing it.
How do you execute a transfer in Solas?
Transfers in Solas replace the multi-step manual process most registry workflows still require. Select the certificates, specify the recipient, confirm. Solas queues the transfer through the appropriate registry and triggers an automatic resync once it completes, keeping your inventory position current.
For batch transfers, you can select across vintages, facilities, or programs in a single action. An inbox and outbox workflow tracks the full status of each transfer (staged, submitted, confirmed) so no transaction disappears into a registry queue without visibility.
Most reconciliation errors in REC trading happen not because data is wrong, but because it's invisible at the moment it matters.
For workflows that require review before execution, Solas supports approval policies. Organizations configure which operations require sign-off, and approvers are assigned by role within the Solas platform. A trader initiates the transfer; a designated approver reviews and confirms before the registry action fires. The full sequence (who initiated, who approved, and when) is logged in task history.
Transfer records include the originating registry, certificate IDs, counterparty, timestamp, and any tags applied to the batch. This is the evidence layer for delivery confirmation and dispute resolution.
How do you retire RECs in Solas?
Retirements execute directly from the inventory view. Select the certificates, choose the applicable program (RE100, GHG Protocol Scope 2 Guidance, state RPS, or other designation), add any notes, and confirm. Solas submits the retirement to the relevant registry and logs the full record.
For organizations managing bulk retirements, Solas lets you select and retire across multiple certificates in a single workflow; the same step most teams still execute by logging into each registry separately.
Like transfers, retirements support approval policies. If your organization requires a second sign-off before a retirement is finalized, that step is built into the workflow rather than handled offline. The approver is a named Solas member with the appropriate role, and the approval is captured in task history.
Retirement records include certificate IDs, registry source, facility, vintage, RPS eligibility designation, retirement date, program designation, notes, and any tags applied, structured for compliance documentation and audit purposes.
How does Solas maintain an audit trail?
Every action in Solas is logged in task history with a timestamp and the user who executed it. This covers registry connections, inventory syncs, tag assignments, transfers, approvals, and retirements. Nothing happens silently.
Critically, task history captures both user-initiated actions and platform-initiated ones. When a transfer completes, Solas automatically queues a resync which appears in task history too, showing exactly which certificates changed, when, and why. You're not just auditing what people did. You're auditing everything the system did on their behalf.
For compliance and audit functions, task history provides a structured record of what happened, when, and who authorized it.
Approval policies add a second layer: when a retirement or transfer requires sign-off, the record shows who initiated it and which Solas member approved it by role. For organizations where REC operations have historically lived in one person's spreadsheets and registry logins, this is the shift from key-man risk to institutional memory.
The audit trail is exportable. It can accompany a Scope 2 submission, support a regulatory inquiry, or satisfy an internal audit without requiring anyone to reconstruct a decision log from email chains.
Operational credibility in energy markets increasingly depends on documentation as much as execution. The ability to show that a retirement happened correctly and at the right time is becoming the standard for RE100 members, GHG Protocol reporters, and RPS compliance filers alike.
How does Innovo support REC operations at scale?
Solas is Innovo's REC operations platform, built as financial market infrastructure rather than registry software. It connects to M-RETS, WREGIS, NEPOOL GIS, PJM-GATS, and Evident, aggregating inventory across all accounts and sub-accounts into a single interface. The platform normalizes certificate data across registries, standardizing fields like RPS eligibility, tier and class designations, and vintage into a consistent model that is filterable and exportable.
Transfers and retirements execute through the registry integrations directly, with automatic resyncs after each operation, role-based approval policies, and full task history for audit. Solas fits into existing stacks via API; one integration, one language, across all supported registries, rather than replacing them. For organizations managing compliance across multiple programs or moving volume across many counterparties, it reduces operational surface area without reducing control.
The REC market is not operationally complex because the assets are complex. It's operationally complex because the infrastructure underneath it was never built to handle volume, multi-registry positions, or audit-grade documentation at scale. A book you can actually stand behind starts with infrastructure that was built for the job.
Frequently Asked Questions
Does Solas replace my existing registry accounts?
No. Solas connects to your existing accounts using your current credentials and access rights. Your registry relationships, account ownership, and compliance standings remain unchanged. Solas reads your position and enables actions through the same access rights you already hold.
How is Solas different from what M-RETS or PJM-GATS already provide?
M-RETS and PJM-GATS are single-registry portals. They track certificates issued and retired within their own systems using registry-specific data structures and field names. Solas aggregates across all supported registries, normalizes certificate data into a consistent model, and provides cross-registry workflow capabilities like bulk transfers, retirements, and unified task history that no individual registry offers.
Can different users in my organization see different inventory views?
Yes. Each user configures their own column layout, visible fields, and saved views without affecting other users or the underlying data. A compliance analyst and a trader can work from the same inventory without working from the same screen.
How do approval policies work in Solas?
Approval policies are configured at the organization level and apply to specific operation types, such as transfers or retirements. Approvers are Solas members assigned by role. When an operation requires approval, the initiating user submits it, the designated approver reviews and confirms, and the registry action fires only after approval is granted. The full sequence is captured in task history.
Can Solas be integrated into our existing systems via API?
Yes. The Solas API exposes every platform operation through a single integration. The registry is passed as a parameter, so teams connecting via API don't need separate integrations for connected registries. Solas handles the registry-specific plumbing. API documentation is available within the Developer Portal after onboarding.
Does Solas support RPS compliance tracking across multiple states?
Yes. Solas normalizes RPS eligibility data across registries into a consistent structured field. Users can filter inventory by RPS eligibility, apply tags for specific carve-out categories or compliance years, and export retirement records structured for state RPS filings.
Contact us to learn more about Solas.