Varför egna integrationer för energiattributcertifikatregister (EAC) är en fälla

Företags tekniska team hamnar ofta i att utvärdera nätet av Energiattributcertifikat (EAC) register på marknaden och inser snabbt att de måste fatta ett beslut.

• A) Ska vi försöka bygga dessa integrationer själva?
• B) Ska vi låta vårt team fortsätta slösa timmar på att hoppa mellan plattformar?
• C) Ska vi leta efter en befintlig integration?

Helt ärligt: vi är här som programvaruleverantör för att avråda er från A och B. Ni får tro oss när vi säger att det inte bara beror på att vi har ett affärsintresse i saken, utan på att renare insyn över marknader i grunden är en svår uppgift som det tog Soldera flera år att lösa - vi grundades 2024 och har sedan dess arbetat med vår Registry Bridge infrastruktur.

När många av de register ni vill integrera med helt saknar API:er handlar det i praktiken om skräddarsydd sammanbindande teknik - anpassade byggen för utförande på varje marknad. Era utvecklare kommer aldrig att möta samma uppgift två gånger: de måste sprida sin insats över landsspecifika portaler när de försöker förena olika inloggningsvägar, kontoregler, överföringsprotokoll, skilda bevispaket för annullering och rapporteringsdeadlines som finns mellan marknader.

Varför är integrationer med EAC-register så komplexa? Har vissa normala API:er?

Man skulle kunna anta att alla har API:er, men nej. Registren byggdes av olika programvaruteam som kontrollerade administrativa system för myndigheter, inte som utvecklarvänliga produkter (eller användarvänliga produkter, för den delen). Ta Europas GO-system som exempel: nätet av AIB-anslutna EECS GO-register kretsar i grunden kring ett interoperabelt avvecklingssystem, "AIB Hub" - men på ytan är registren själva inte likvärdiga.

Om du till exempel var behörig myndighet inom en nationell regering (häng med här), och ville starta ditt eget register, skulle du sannolikt undersöka vilka som byggt befintliga register för att säkerställa att din produkt kunde uppfylla AIB-Hub-standarden. Du skulle mötas av en lista med 9 olika tjänsteleverantörer (vid skrivande stund), över 30+ register, där var och en har byggt en plattform avsedd för en kontrollerad och sammanlänkad överföringsupplevelse sinsemellan - men ingen av tjänsteleverantörerna har tagit hänsyn till att användare använder flera register. De vill logga in i register på olika marknader för att styra hela sin portfölj. Ändå erbjuder bara vissa API:er. Här är en icke uttömmande översikt på hög nivå över problemets omfattning på stora marknader

• Tysklands HNKR-register har inget publikt API: https://www.hknr.de/Uba
• Spaniens CNMC-register har inget publikt API: https://gdo.cnmc.es/
• Nederländernas CertiQ har inget publikt API: https://verticer.eu/en/
• Tre av Belgiens register har inga publika API:er
• Polens TGE RGP-register har inget publikt API: https://rgp.tge.pl/
• Sveriges CESAR-register har ett mycket funktionsbegränsat API: https://cesar.energimyndigheten.se/sv/
• Finlands Finextra-plattform har ett funktionsbegränsat API: https://go.finextra.fi/app/login

Och det är bara för en handfull europeiska register (utan att räkna de otaliga "nischade" marknaderna runt om på kontinenten) som betjänar deltagare på marknaden för ursprungsgarantier. Också värt att komma ihåg: Storbritanniens OFGEM RER-system för hantering av REGO och Evidents I-REC system har båda unika regler, inloggningar och layouter, inbyggda i sina olika operativa processer, vilket kräver olika dokumentformat.

Den övergripande lärdomen är att om ert team antar (som vi själva en gång gjorde, för flera år sedan) att det finns ett stabilt REST-gränssnitt under varje enskild marknad, kommer det riktigt besvärliga arbetet senare. Vi använder "besvärligt" här främst eftersom det är ett flerdimensionellt problem: svårigheten kommer inte bara ur teknisk integration, utan ur att säkerställa att er integration följer lokal marknadskunskap i ett format som uppfyller kraven. För utvecklare har marknadskunskap mycket lite med kärnteknisk förmåga att göra.

Var anpassade integrationer vanligtvis orsakar problem:

• Löpande underhållskostnad: Portalers layouter ändras alltför ofta utan varning eller versionshanterade utvecklarnoter.
• Tidskrävande integrationshinder: Manuell autentisering och egenheter i 2FA orsakar allvarligt inkonsekventa stopp som kräver kreativa och dyra kringlösningar, såsom system med permanent drifttid och löpande kostnader
• Lära genom att göra: Först när transaktioner behandlas i stor skala kan vissa verkliga registeregenheter redas ut. Tro oss, vi har mött verkligheten med hårda, irrationella fel på registernivå som bara dyker upp när bevis behövs akut. Ibland har vi själva behövt flagga dessa buggar till en registeroperatör, och de åtgärdades.
• Nedströmskonsekvenser: Konsekvenser som uppstår när det finns luckor i era revisionsklara bevis - och dessa luckor uppstår när ni gör ett fel i integrationsprocessen.

Vad bör företagsteam bygga själva?

Vi ser att våra kunder gör en sak bättre än allt annat: sin kärnverksamhet. Så varför slösa tid som kunde läggas på att fokusera på hållbarhetsstrategi? När det gäller att bygga: var pragmatiska. Bygg de interna, företagsfokuserade systemen ovanpå EAC-kopplingar som faktiskt redan fungerar , i stället för att bränna år av produktkapacitet på att underhålla ett privat museum av registergränssnitt. Lyckligtvis finns det EAC-kopplingar som redan fungerar.

Vad är lösningen?

Solderas Registry Bridge är färdig åt er, ett avvecklingslager och API för EAC-certifikat som fungerar som friktionsfri regelefterlevnad från början till slut. Den finns för att lösa exakt detta: vi har driftsatt befintliga konton på varje marknad för att erbjuda ett sömlöst hostat konto och API-yta för att köpa, ta emot, inneha, skicka, sälja, annullera och exportera bevis över 30+ register, inklusive även de mest utmanande marknaderna utan publika API:er. Använd Registry Bridge direkt från Soldera Web App, eller, om er befintliga programvarumiljö kräver programmatiska/integrerade registeråtgärder, kan ert team använda Solderas API som den förbyggda kopplingen under. Den möjliggör alla registerbeteenden: inklusive automatiskt dirigerade annulleringar via lokala register där sådana finns.

Detta är också verksamhetskritiskt: lokala, registerstödda annulleringscertifikat är tydligt bästa praxis för trovärdiga anspråk på förnybar el enligt RE100 , och detta förbises ofta - trots att lokala annulleringar nästan säkert kommer att möta mer revisionsgranskning när geografisk matchning blir mer relevant för hållbarhetsteam (se vår artikel om reglerna för skärpningen av GHG-P mot geografisk matchning). Så i stället för att bygga om registerlabyrinten själv, lita på dem som har gått den besvärliga vägen före er så att ni slipper.