Bouwen of kopen: moet je je eigen wisselkoers-API ontwikkelen?

Beslissen of je je eigen wisselkoers-API gaat bouwen of een beheerde koopt, is een van de eerste echte architectuurbeslissingen die elk team dat met geld in meer dan één valuta werkt moet nemen. Op papier lijkt bouwen goedkoop: de Europese Centrale Bank publiceert gratis referentiekoersen, de data is slechts een klein XML-bestand, en hoe moeilijk kan het zijn om een feed te parsen en via HTTP aan te bieden? In de praktijk schuilt het grootste deel van de kosten in de kloof tussen een weekendprototype en een productieklare koersdienst. Deze gids ontleedt de echte afwegingen van zelf bouwen versus kopen van een wisselkoers-API, met eerlijke engineeringcijfers, zodat je de weg kiest die echt bij je team past.

Bouwen of kopen in één oogopslag

Hier is de korte versie voordat we de details induiken. De keuze gaat zelden over de vraag of je een koersfeed kunt bouwen — vrijwel elke competente engineer kan dat — maar of de doorlopende kosten van bezit het waard zijn vergeleken met een paar dollar per maand betalen.

Wat "het zelf bouwen" werkelijk inhoudt

De reden dat bouwen-of-kopen mensen in de war brengt, is dat de demo echt makkelijk is en het productiesysteem echt niet. Laten we doornemen waar je je werkelijk voor inschrijft.

De ruwe data ophalen

De meest gebruikte gratis bron is de Europese Centrale Bank, die euro-referentiekoersen één keer per werkdag publiceert, meestal rond 16:00 CET. Dat is de basis achter veel "gratis" koersfeeds, waaronder opensourceprojecten zoals Frankfurter, dat nu data van 84 centrale banken over 201 valuta's combineert.

Twee dingen vallen meteen op. Ten eerste is de ECB-feed EUR-gebaseerd en wordt slechts eenmaal per werkdag bijgewerkt — geen weekendupdates, geen intraday-beweging, geen koersen op TARGET-feestdagen. Als je gebruikers op zondag transacties doen of koersen verwachten die gedurende de dag bewegen, volstaat een dagelijkse EUR-feed niet. Ten tweede dekt de ECB ongeveer 30 valuta's. Zodra je een exotisch paar, een metaal of een cryptokoers nodig hebt, moet je weer zelf meerdere aanbieders verzamelen en afstemmen.

Hier is het "makkelijke" deel dat iedereen ziet — de dagelijkse ECB-XML ophalen en parsen:

import requests
import xml.etree.ElementTree as ET

URL = "https://www.ecb.europa.eu/stats/eurofxref/eurofxref-daily.xml"
NS = {"x": "http://www.ecb.int/vocabulary/2002-08-01/eurofxref"}

resp = requests.get(URL, timeout=10)
root = ET.fromstring(resp.content)

rates = {"EUR": 1.0}
for cube in root.findall(".//x:Cube[@currency]", NS):
    rates[cube.attrib["currency"]] = float(cube.attrib["rate"])

print(rates["USD"])  # EUR -> USD reference rate

Dat zijn misschien 15 regels. Het lijkt klaar. Het is niet klaar.

Parsen, opslaan en aanbieden

Een echte dienst heeft meer nodig dan de laatste momentopname. Je moet de koersen van elke dag bewaren om historische zoekopdrachten te kunnen beantwoorden (denk aan facturen, terugbetalingen, boekhouding en belastingrapportage die de koers van een specifieke datum moeten gebruiken). Dat betekent een databaseschema, een dagelijkse ingestietaak, retry-logica voor wanneer het ECB-endpoint traag is of plat ligt, en basisvaluta-omrekenwiskunde om "USD naar JPY" te beantwoorden terwijl je bron alleen "EUR naar alles" geeft.

Basisomrekening via een pivotvaluta is eenvoudige rekenkunde, maar makkelijk subtiel fout te doen:

def convert(rates, amount, base, quote):
    # rates are all relative to EUR
    if base != "EUR":
        amount = amount / rates[base]   # to EUR
    return round(amount * rates[quote], 6)

convert(rates, 100, "USD", "JPY")

Vervolgens moet je dit via een API blootstellen met caching, rate limiting, authenticatie en CORS als browsers het aanroepen. Niets hiervan is op zichzelf moeilijk. Alles bij elkaar is het een klein product.

De verborgen onderhoudslast

Dit is het deel dat het prototype nooit onthult. Zodra je bedrijf van de feed afhankelijk is, neem je een reeks terugkerende verplichtingen op je: de ingestietaak monitoren en alarmeren wanneer die stilletjes faalt; omgaan met de dagen waarop het formaat of de URL van de bron verandert; gaten opvullen wanneer een ophaalactie wordt gemist; de dienst opschalen naarmate het verkeer groeit; en de persoon zijn die om 2 uur 's nachts wordt gebeld wanneer een betaalstroom breekt omdat de koersen verouderd raakten. Een koersfeed is geen functie die je eenmaal oplevert. Het is een systeem dat je voor onbepaalde tijd draait.

De werkelijke kosten van bouwen

Teams onderschatten dit stelselmatig omdat de post die ertoe doet — engineeringtijd — niet op een factuur verschijnt. Een conservatieve uitsplitsing voor een productieklare, zelf gehoste feed ziet er zo uit:

1. Initiële bouw: ingestie, opslag, omrekening, API-laag, authenticatie, tests — doorgaans een tot drie weken gericht engineeringwerk.
2. Infrastructuur: een kleine server of container plus een database. Bescheiden in dollars, maar nooit nul.
3. Doorlopend onderhoud: realistisch een paar uur per maand in stabiele toestand, met pieken telkens wanneer een bron breekt of de eisen groeien.
4. Opportuniteitskosten: elk uur besteed aan het draaien van een standaard koersfeed is een uur dat niet naar het product gaat waar je klanten echt voor betalen.

Zet een gemiddeld engineeringtarief tegenover die weken en de "gratis" feed kost stilletjes duizenden dollars alleen al in het eerste kwartaal — voordat je een enkele realtimekoers of een enkele historische query hebt geleverd die je bron niet biedt. Vergelijk dat met een beheerde gratis valuta-API die bij nul dollar begint en een betaald niveau dat voor de meeste teams ruim onder de $129 per maand blijft.

Wat je krijgt als je een valuta-API koopt

Kopen brengt die hele bouw terug tot één HTTP-verzoek. Een beheerde aanbieder als Finexly regelt bronvergaring, normalisatie, basisomrekening, historische opslag en uptime, zodat jij een schone, consistente interface gebruikt. Dezelfde taak die hierboven een schema en een ingestiepijplijn vergde, wordt:

curl "https://api.finexly.com/v1/latest?base=USD&symbols=EUR,GBP,JPY&apikey=YOUR_API_KEY"

{
  "success": true,
  "base": "USD",
  "timestamp": 1760000000,
  "rates": {
    "EUR": 0.9241,
    "GBP": 0.7886,
    "JPY": 156.32
  }
}

Elke basisvaluta werkt op elk niveau — geen EUR-only-beperking — en historische data is een wijziging van één parameter in plaats van een database die je onderhoudt:

curl "https://api.finexly.com/v1/historical?base=USD&symbols=EUR&date=2026-01-15&apikey=YOUR_API_KEY"

Wat je echt koopt is data die je niet hoeft te vergaren, omrekeningen die je niet hoeft te verifiëren en uptime die je niet hoeft te bezitten. Dekking van 170+ valuta's, reacties onder 50 ms en realtime-updates zijn standaard. De volledige set endpoints staat in de Finexly API-documentatie, en je kunt aanbieders naast elkaar vergelijken met de vergelijkingstool.

Wanneer bouwen zinvol is

Bouwen is niet altijd de verkeerde keuze. Zelf hosten is echt zinvol wanneer:

• Je behoeften klein en statisch zijn. Een dagelijkse EUR-gebaseerde referentiekoers voor een intern dashboard zonder historische of realtime-eisen is een legitieme reden om de ECB-feed zelf in te kapselen.
• Je harde eisen hebt rond dataresidentie of air-gap. Als koersen om compliancereden je infrastructuur niet mogen verlaten, kan het zelf hosten van een opensourcefeed als Frankfurter verplicht zijn.
• Koersdata je kernproduct is. Als je een forex-handelsplatform bouwt waar de koersengine het onderscheidend vermogen is, kan volledig eigendom de kosten waard zijn.

Voor alle anderen is het bouwen van een standaard koersfeed het oplossen van een probleem dat al beter is opgelost.

Wanneer kopen zinvol is

Kopen wint in het gangbare geval, en de signalen zijn makkelijk te herkennen:

• Je hebt elke willekeurige basisvaluta nodig, niet alleen EUR.
• Je hebt realtime- of intraday-beweging nodig, niet één dagelijkse momentopname.
• Je hebt historische koersen op willekeurige data nodig voor facturatie, boekhouding of rapportage.
• Je hebt brede dekking nodig inclusief exoten, metalen of crypto.
• Je levert liever productfuncties dan dat je infrastructuur draait.
• Je wilt dat iemand anders verantwoordelijk is voor uptime en een SLA.

Als je er twee of meer hebt aangevinkt, valt de rekensom bijna altijd in het voordeel van kopen uit.

Een hybride aanpak: koop de data, cache die zelf

De slimste productieopstellingen zijn zelden puur bouwen of puur kopen. Ze kopen de data en cachen die lokaal om kosten en latentie te beheersen. Je krijgt de dekking en betrouwbaarheid van een beheerde aanbieder en houdt tegelijk het aantal verzoeken — en je rekening — laag. Hier is een minimale cachelaag in Node.js:

const cache = new Map();
const TTL_MS = 60 * 60 * 1000; // refresh hourly

async function getRates(base = "USD") {
  const hit = cache.get(base);
  if (hit && Date.now() - hit.time < TTL_MS) return hit.rates;

  const url = `https://api.finexly.com/v1/latest?base=${base}&apikey=${process.env.FINEXLY_KEY}`;
  const res = await fetch(url);
  const data = await res.json();

  cache.set(base, { rates: data.rates, time: Date.now() });
  return data.rates;
}

Dit patroon geeft je het beste van twee werelden: je draait geen ingestiepijplijn, maar je doet ook niet bij elke paginaweergave een netwerkaanroep. Voor diepere patronen, zie onze gids over best practices voor caching en foutafhandeling. Naarmate het volume groeit, schalen de prijsplannen met je mee in plaats van een herbouw af te dwingen.

Een snelle beslischecklist

Loop deze vragen eerlijk door:

1. Heb ik meer nodig dan een dagelijkse EUR-momentopname? Zo ja, neig naar kopen.
2. Heb ik historische koersen voor specifieke data nodig? Zo ja, neig naar kopen.
3. Is koersdata mijn kernproduct of een ondersteunende functie? Als ondersteunend, neig naar kopen.
4. Heb ik een compliancereden waarom data mijn infrastructuur niet mag verlaten? Zo ja, neig naar bouwen (zelf hosten).
5. Is de tijd van het team beter besteed aan het product? Bijna altijd ja — neig naar kopen.

Voor de grote meerderheid van fintech-bouwers, SaaS-platforms en e-commerceteams wijst het antwoord dezelfde kant op: koop het standaardonderdeel, bouw het onderscheidend vermogen.

Veelgestelde vragen

Is het goedkoper om mijn eigen wisselkoers-API te bouwen? Alleen als je behoeften triviaal zijn en nooit groeien. De databron kan gratis zijn via de ECB, maar de engineeringtijd om een productiefeed te bouwen en onderhouden — ingestie, opslag, omrekening, uptime, monitoring — kost in het eerste kwartaal doorgaans meer dan jaren van een beheerd API-abonnement.

Kan ik gewoon de gratis ECB-feed direct gebruiken? Dat kan, met twee grote kanttekeningen: hij is EUR-gebaseerd en wordt slechts eenmaal per werkdag bijgewerkt, zonder weekend- of intraday-koersen. Voor interne dashboards is dat prima; voor iets dat naar de gebruiker gericht of transactioneel is meestal niet.

Wat is het verschil tussen Frankfurter en een betaalde API zoals Finexly? Frankfurter is een uitstekende gratis, opensourcefeed gebouwd op referentiekoersen van centrale banken, zonder API-sleutel en zonder quota, ideaal voor laagdrempelig of zelf gehost gebruik. Een betaalde API als Finexly voegt omrekening naar elke basis, realtime-updates, 170+ valuta's, gegarandeerde uptime/SLA en ondersteuning toe — wat je nodig hebt zodra geld van de koersen afhangt.

Kan ik beide aanpakken combineren? Ja, en de meeste volwassen teams doen dat. Koop de data bij een beheerde API voor dekking en betrouwbaarheid, en cache die vervolgens lokaal met een verstandige TTL om latentie en aantal verzoeken — en kosten — laag te houden.

Hoe migreer ik van een zelfgebouwde feed naar een beheerde API? Vervang de databron van je interne koersfunctie door één API-aanroep, behoud je bestaande cachelaag en vul historische behoeften aan via het historische endpoint van de aanbieder. Het is meestal een paar uur werk, geen herschrijving.

Klaar om het bouwen over te slaan en in plaats daarvan de functie te leveren? Haal je gratis Finexly API-sleutel — geen creditcard nodig. Begin met 1.000 gratis verzoeken per maand over 170+ valuta's, en upgrade pas wanneer je verkeer echt groeit.