Selbst bauen oder kaufen: Sollten Sie Ihre eigene Wechselkurs-API entwickeln?

Die Entscheidung, ob man eine eigene Wechselkurs-API entwickeln oder eine verwaltete kaufen sollte, ist eine der ersten echten Architekturentscheidungen, die jedes Team treffen muss, das Geld in mehr als einer Währung verarbeitet. Auf dem Papier wirkt Selbstbauen günstig: Die Europäische Zentralbank veröffentlicht Referenzkurse kostenlos, die Daten sind nur eine kleine XML-Datei, und wie schwer kann es sein, einen Feed zu parsen und über HTTP auszuliefern? In der Praxis steckt der Großteil der Kosten in der Lücke zwischen einem Wochenend-Prototyp und einem produktionsreifen Kursdienst. Dieser Leitfaden schlüsselt die wahren Kompromisse von Selbst-bauen vs. Kaufen einer Wechselkurs-API mit ehrlichen Engineering-Zahlen auf, damit Sie den Weg wählen, der wirklich zu Ihrem Team passt.

Selbst bauen oder kaufen auf einen Blick

Hier die Kurzfassung, bevor wir ins Detail gehen. Bei der Wahl geht es selten darum, ob Sie einen Kurs-Feed bauen können — fast jeder kompetente Entwickler kann das —, sondern darum, ob sich die laufenden Kosten des Besitzes lohnen, verglichen mit ein paar Dollar im Monat.

Was „selbst bauen" wirklich bedeutet

Der Grund, warum Selbst-bauen-vs.-Kaufen die Leute verwirrt, ist, dass die Demo wirklich einfach ist und das Produktionssystem wirklich nicht. Sehen wir uns an, worauf Sie sich tatsächlich einlassen.

Die Rohdaten beschaffen

Die häufigste kostenlose Quelle ist die Europäische Zentralbank, die Euro-Referenzkurse einmal pro Geschäftstag veröffentlicht, üblicherweise gegen 16:00 Uhr MEZ. Das ist die Grundlage hinter vielen „kostenlosen" Kurs-Feeds, einschließlich Open-Source-Projekten wie Frankfurter, das mittlerweile Daten von 84 Zentralbanken über 201 Währungen kombiniert.

Zwei Dinge fallen sofort ins Gewicht. Erstens ist der EZB-Feed EUR-basiert und aktualisiert sich nur einmal pro Geschäftstag — keine Wochenend-Updates, keine Intraday-Bewegung, keine Kurse an TARGET-Feiertagen. Wenn Ihre Nutzer sonntags Transaktionen tätigen oder Kurse erwarten, die sich im Tagesverlauf bewegen, reicht ein täglicher EUR-Feed nicht. Zweitens deckt die EZB rund 30 Währungen ab. Sobald Sie ein exotisches Paar, ein Metall oder einen Krypto-Kurs brauchen, müssen Sie wieder selbst mehrere Anbieter beschaffen und abgleichen.

Hier ist der „einfache" Teil, den jeder sieht — das tägliche EZB-XML abrufen und 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

Das sind vielleicht 15 Zeilen. Es sieht fertig aus. Ist es nicht.

Parsen, speichern und ausliefern

Ein echter Dienst braucht mehr als die letzte Momentaufnahme. Sie müssen die Kurse jedes Tages persistieren, um historische Abfragen beantworten zu können (denken Sie an Rechnungen, Erstattungen, Buchhaltung und Steuerberichte, die den Kurs eines bestimmten Datums verwenden müssen). Das bedeutet ein Datenbankschema, einen täglichen Ingestion-Job, Retry-Logik für Zeiten, in denen der EZB-Endpunkt langsam oder ausgefallen ist, und Basiswährungs-Umrechnungsmathematik, um „USD zu JPY" zu beantworten, wenn Ihre Quelle nur „EUR zu allem" liefert.

Die Basisumrechnung über eine Pivot-Währung ist einfache Arithmetik, aber leicht subtil falsch zu machen:

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")

Dann müssen Sie das über eine API mit Caching, Rate-Limiting, Authentifizierung und CORS bereitstellen, falls Browser sie aufrufen. Nichts davon ist für sich genommen schwer. Alles zusammen ist ein kleines Produkt.

Die versteckte Wartungslast

Das ist der Teil, den der Prototyp nie zeigt. Sobald Ihr Geschäft vom Feed abhängt, übernehmen Sie eine Reihe wiederkehrender Pflichten: den Ingestion-Job überwachen und alarmieren, wenn er stillschweigend fehlschlägt; die Tage bewältigen, an denen sich Format oder URL der Quelle ändert; Lücken füllen, wenn ein Abruf verpasst wird; den Dienst skalieren, wenn der Traffic wächst; und die Person sein, die um 2 Uhr nachts geweckt wird, wenn ein Zahlungsfluss bricht, weil die Kurse veraltet sind. Ein Kurs-Feed ist kein Feature, das Sie einmal ausliefern. Es ist ein System, das Sie unbefristet betreiben.

Die wahren Kosten des Selbstbauens

Teams unterschätzen das regelmäßig, weil der entscheidende Posten — Entwicklerzeit — auf keiner Rechnung auftaucht. Eine konservative Aufschlüsselung für einen produktionsreifen, selbst gehosteten Feed sieht so aus:

1. Erstaufbau: Ingestion, Speicherung, Umrechnung, API-Schicht, Authentifizierung, Tests — typischerweise ein bis drei Wochen konzentrierte Entwicklungsarbeit.
2. Infrastruktur: ein kleiner Server oder Container plus eine Datenbank. Bescheiden in Dollar, aber nie null.
3. Laufende Wartung: realistisch ein paar Stunden im Monat im stabilen Betrieb, mit Spitzen, sobald eine Quelle bricht oder die Anforderungen wachsen.
4. Opportunitätskosten: Jede Stunde, die für den Betrieb eines Standard-Kurs-Feeds aufgewendet wird, ist eine Stunde, die nicht in das Produkt fließt, für das Ihre Kunden tatsächlich zahlen.

Setzen Sie einen durchschnittlichen Entwickler-Stundensatz gegen diese Wochen, und der „kostenlose" Feed kostet still und leise schon im ersten Quartal Tausende Dollar — bevor Sie einen einzigen Echtzeitkurs oder eine einzige historische Abfrage ausgeliefert haben, die Ihre Quelle nicht liefert. Vergleichen Sie das mit einer verwalteten kostenlosen Währungs-API, die bei null Dollar beginnt, und einer Bezahlstufe, die für die meisten Teams deutlich unter $129 im Monat liegt.

Was Sie beim Kauf einer Währungs-API erhalten

Kaufen reduziert diesen gesamten Aufbau auf eine HTTP-Anfrage. Ein verwalteter Anbieter wie Finexly kümmert sich um Quelle, Normalisierung, Basisumrechnung, historische Speicherung und Verfügbarkeit, sodass Sie eine saubere, konsistente Schnittstelle nutzen. Die gleiche Aufgabe, die oben ein Schema und eine Ingestion-Pipeline erforderte, wird zu:

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
  }
}

Jede Basiswährung funktioniert auf jeder Stufe — keine EUR-nur-Beschränkung — und historische Daten sind eine Änderung eines Parameters statt einer Datenbank, die Sie pflegen:

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

Was Sie wirklich kaufen, sind Daten, die Sie nicht beschaffen müssen, Umrechnungen, die Sie nicht verifizieren müssen, und Verfügbarkeit, die Sie nicht besitzen müssen. Eine Abdeckung von über 170 Währungen, Antwortzeiten unter 50 ms und Echtzeit-Updates gehören zum Standard. Der vollständige Satz an Endpunkten ist in der Finexly-API-Dokumentation beschrieben, und Sie können Anbieter mit dem Vergleichstool nebeneinander vergleichen.

Wann Selbstbauen Sinn ergibt

Selbstbauen ist nicht immer die falsche Wahl. Selbst-Hosting ergibt wirklich Sinn, wenn:

• Ihre Anforderungen winzig und statisch sind. Ein täglicher EUR-basierter Referenzkurs für ein internes Dashboard ohne historische oder Echtzeitanforderungen ist ein legitimer Grund, den EZB-Feed selbst zu kapseln.
• Sie strenge Anforderungen an Datenresidenz oder Air-Gap haben. Wenn Kurse aus Compliance-Gründen Ihre Infrastruktur nicht verlassen dürfen, kann das Selbst-Hosting eines Open-Source-Feeds wie Frankfurter zwingend sein.
• Kursdaten Ihr Kernprodukt sind. Wenn Sie eine Forex-Trading-Plattform bauen, bei der die Kurs-Engine das Unterscheidungsmerkmal ist, kann der vollständige Eigenbesitz die Kosten wert sein.

Für alle anderen heißt einen Standard-Kurs-Feed zu bauen, ein Problem zu lösen, das bereits besser gelöst wurde.

Wann Kaufen Sinn ergibt

Kaufen gewinnt im häufigen Fall, und die Signale sind leicht zu erkennen:

• Sie brauchen jede beliebige Basiswährung, nicht nur EUR.
• Sie brauchen Echtzeit- oder Intraday-Bewegung, nicht eine einzige tägliche Momentaufnahme.
• Sie brauchen historische Kurse zu beliebigen Daten für Rechnungsstellung, Buchhaltung oder Reporting.
• Sie brauchen breite Abdeckung einschließlich Exoten, Metallen oder Krypto.
• Sie liefern lieber Produktfeatures aus, als Infrastruktur zu betreiben.
• Sie wollen, dass jemand anderes für Verfügbarkeit und ein SLA geradesteht.

Wenn Sie zwei oder mehr davon angekreuzt haben, spricht die Rechnung fast immer für das Kaufen.

Ein hybrider Ansatz: Daten kaufen, selbst cachen

Die klügsten Produktions-Setups sind selten reines Bauen oder reines Kaufen. Sie kaufen die Daten und cachen sie lokal, um Kosten und Latenz zu kontrollieren. Sie erhalten die Abdeckung und Zuverlässigkeit eines verwalteten Anbieters und halten zugleich das Anfragevolumen — und Ihre Rechnung — niedrig. Hier ist eine minimale Cache-Schicht 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;
}

Dieses Muster gibt Ihnen das Beste aus beiden Welten: Sie betreiben keine Ingestion-Pipeline, machen aber auch nicht bei jedem Seitenaufruf einen Netzwerkaufruf. Für tiefergehende Muster siehe unseren Leitfaden zu Best Practices für Caching und Fehlerbehandlung. Wenn das Volumen wächst, skalieren die Preispläne mit Ihnen, statt einen Neuaufbau zu erzwingen.

Eine schnelle Entscheidungs-Checkliste

Gehen Sie diese Fragen ehrlich durch:

1. Brauche ich mehr als eine tägliche EUR-Momentaufnahme? Wenn ja, tendieren Sie zum Kaufen.
2. Werde ich historische Kurse für bestimmte Daten brauchen? Wenn ja, tendieren Sie zum Kaufen.
3. Sind Kursdaten mein Kernprodukt oder ein unterstützendes Feature? Wenn unterstützend, tendieren Sie zum Kaufen.
4. Habe ich einen Compliance-Grund, warum Daten meine Infrastruktur nicht verlassen dürfen? Wenn ja, tendieren Sie zum Bauen (Selbst-Hosting).
5. Ist die Zeit des Teams besser im Produkt investiert? Fast immer ja — tendieren Sie zum Kaufen.

Für die große Mehrheit der Fintech-Bauer, SaaS-Plattformen und E-Commerce-Teams weist die Antwort in dieselbe Richtung: Kaufen Sie das Standardgut, bauen Sie das Unterscheidungsmerkmal.

Häufig gestellte Fragen

Ist es günstiger, meine eigene Wechselkurs-API zu bauen? Nur wenn Ihre Anforderungen trivial sind und nie wachsen. Die Datenbeschaffung kann über die EZB kostenlos sein, aber die Entwicklerzeit zum Bauen und Warten eines Produktions-Feeds — Ingestion, Speicherung, Umrechnung, Verfügbarkeit, Monitoring — kostet im ersten Quartal in der Regel mehr als Jahre eines verwalteten API-Abonnements.

Kann ich einfach den kostenlosen EZB-Feed direkt verwenden? Können Sie, mit zwei großen Vorbehalten: Er ist EUR-basiert und aktualisiert sich nur einmal pro Geschäftstag, ohne Wochenend- oder Intraday-Kurse. Für interne Dashboards ist das in Ordnung; für alles Nutzerorientierte oder Transaktionale meist nicht.

Was ist der Unterschied zwischen Frankfurter und einer kostenpflichtigen API wie Finexly? Frankfurter ist ein hervorragender kostenloser Open-Source-Feed auf Basis von Zentralbank-Referenzkursen, ohne API-Schlüssel und ohne Kontingente, ideal für unkritische oder selbst gehostete Nutzung. Eine kostenpflichtige API wie Finexly ergänzt Umrechnung in jede Basis, Echtzeit-Updates, über 170 Währungen, garantierte Verfügbarkeit/SLA und Support — das, was Sie brauchen, sobald Geld von den Kursen abhängt.

Kann ich beide Ansätze kombinieren? Ja, und die meisten reifen Teams tun das. Kaufen Sie die Daten von einer verwalteten API für Abdeckung und Zuverlässigkeit und cachen Sie sie dann lokal mit einem sinnvollen TTL, um Latenz und Anfragevolumen — und Kosten — niedrig zu halten.

Wie migriere ich von einem selbst gebauten Feed zu einer verwalteten API? Tauschen Sie die Datenquelle Ihrer internen Kursfunktion gegen einen einzigen API-Aufruf, behalten Sie Ihre bestehende Cache-Schicht und füllen Sie historische Bedürfnisse über den historischen Endpunkt des Anbieters auf. Das sind meist ein paar Stunden Arbeit, keine Neuentwicklung.

Bereit, das Selbstbauen zu überspringen und stattdessen das Feature auszuliefern? Holen Sie sich Ihren kostenlosen Finexly-API-Schlüssel — keine Kreditkarte nötig. Starten Sie mit 1.000 kostenlosen Anfragen pro Monat über 170+ Währungen und upgraden Sie erst, wenn Ihr Traffic tatsächlich wächst.