Vorheriger Artikel Nächster Artikel

Wir brauchen eine Online-Banking-API für Deutschland

Zahlreiche Banking-Schnittstellen stehen in Deutschland zur Verfügung und viele Produkte und Angebote werden dadurch überhaupt erst möglich. Das ist an sich eine gute Sache. Der nächste wichtige Schritt ist aber eine einheitliche Banking-API.

Wir brauchen eine Online-Banking-API für Deutschland

Der deutsche Zahlungsverkehr und das darauf aufbauende Online-Banking sind im internationalen Vergleich technisch gut gelöst. Weitestgehend vereinheitliche und zumeist offene Schnittstellen wie HBCI und FIN/TS im Privat- und Geschäftskundenumfeld, sowie FTAM und EBICS im Firmenkundensegment, haben zu einem hocheffizienten System mit einer weiten Verbreitung und Nutzung geführt.

Produkte auf Basis offener Schnittstellen

Aufbauend auf diesen von den Banken, aus der Btx-Historie begründet, kostenlos(!) bereit gestellten Schnittstellen, haben viele Unternehmen in den letzten Jahren ihre Produkte und Services aufgebaut.

Auf diese Art und Weise konnten Banking-Produkte wie StarMoney, sFirm, Multicash, ZVLight, Quicken, iOutbank, Subsembly oder auch Payment-Angebote wie sofortüberweisung entstehen. Auch große und kleine ERP-Lösungen wie SAP, Lexware oder Actindo nutzen die verschiedenen Schnittstellen ebenso wie Buchhaltungslösungen zum Datenaustausch.

(Foto: 401K / flickr.com, Lizenz: CC-BY-SA)

Sind individuelle Anbindungen auf Dauer sinnvoll und zeitgemäß?

Aber ist diese individuelle Anbindung seitens jedes Anbieters an die x verschiedenen Banksysteme/Bankrechenzentren effizient und sinnvoll? Vor allem wenn man bedenkt, dass der vermeintliche Standard HBCI bei Bank 1 nicht dem HBCI-Standard der Bank 2 entspricht, nicht jede Bank HBCI/FINTS unterstützt und zudem jede Bank eigene Sicherheitsverfahren einsetzt (ChipTan, Flikker, SMS-TAN etc.).

Ergänzt man noch den Gedanken, dass die zukünftigen Zahlungsverkehrs-, ERP- oder Buchhaltungs-Lösungen keine installierten Clients im heutigen Sinne mehr sein werden, so meine ich, ist die Idee einer einheitlichen Banking-API mehr als einen Gedanken wert.

Wer kommt als Nutzer der API in Frage?

Als API-Nutzer kommen alle in Frage, die heute die Online-Banking-Schnittstellen der Banken nutzen oder auf Basis einer solchen neu geschaffenen kundenfreundliche Angebote schaffen wollen also z.B.:

  • Online-Banking Tools (von Banken oder Dritten)
  • Personal Finance Management Tools
  • ERP Lösungen
  • Buchhaltungslösungen
  • Branchensoftwarelösungen
  • Payment Service Provider
  • Online-Payment Verfahren
  • Rechnungsdienste
  • und einige mehr...

Was würde der Anbieter der Banking API tun?

  • Betrieb der API als Webservice
  • Spezifikation und Support
  • Pflege der Wege in die Banken
  • Zertifizierung und Zulassung der Anbieter nach transparenten Rules und Regulations
  • regelmäßige Überwachung der Anbieter
  • Abrechnung

Wie könnte ein Business-Case aussehen?

  • Banken erhalten für den Zugriff auf ihre Systeme ein Entgelt
  • Lösungsanbieter welche die API nutzen, zahlen für diese Nutzung
  • API-Anbieter rechnet mit Lösungsanbieter und Banken die Nutzung ab

Was spricht dagegen?

  • Banken wollen den Kunden auf der eigenen Webseite
  • Banken wollen nicht zum reinen Abwickler im Zahlungsverkehr werden
  • Softwareunternehmen verstehen die technische Anbindung an die Banken als Kern-Asset

Fazit

Technisch wäre der Betrieb einer solchen Banking-API schon heute möglich. Allerdings bestehen Grauzonen die potenzielle Anbieter ggf. heute noch von einem Betrieb einer solchen Lösung abhalten: rechtliche (PIN/TAN-Eingabe auf einer nicht von der Bank bereitgestellten Seite) und technische (Screen Scraping).

Lösungen wie Sofortüberweisung oder die angekündigte Web-App von finanzblick gehen aber in diese Richtung und machen mich zuversichtlich, dass eine einheitliche Banking-API unter Einbeziehung der Banken und Sparkassen keine Illusion bleiben muss.

Über den Autor

André M. Bajorat ist seit 1996 in der deutschen Internetlandschaft zu Hause. Als ehemaliger Geschäftsführer der Giropay GmbH und Mitglied der Geschäftsführung der Star Finanz GmbH - der Firma hinter deutschlands populärster Homebanking-Software Star Money - sowie CEO der NumberFour AG, ist er heute als freier Berater im deutschen Startup- und eCommerce-Umfeld aktiv. Sein Blog ist für ihn eine riesige Linksammlung zu den Themen Banking, Payment und Mobile.

Vorheriger Artikel Zurück zur Startseite Nächster Artikel
18 Antworten
  1. von Hansjörg Leichsenring am 12.12.2011 (12:05Uhr)

    Uneingeschränkte Zustimmung dazu. Das würde für viele attraktive Lösungen (wie z.B. PFM) einen deutlichen Schub bedeuten, der letztlich auch den Banken zu gute käme.

    Beste Grüße

    Hansjörg Leichsenring

    http://www.der-bank-blog.de/

    Antworten Teilen
  2. von EU-Zahlungsraum am 12.12.2011 (12:07Uhr)

    Ich will
    - MicroFormate auf Webseiten und Email-Rechnungen => Copy&Paste ins Banking-Programm oder Online-Banking-Website-Text-Feld
    - QR-Codes auf Papier-Rechnungen
    - moneytransfer:// oder payment://-Urls wo dann MEIN Banking-Programm oder Banking-Webseite aufgeht und nicht irgendwelche gefälschten Onlinebanking-Phishing-Sites und die Daten ausgefüllt drin stehen statt mich sie mühselig abtippen lassen zu müssen.

    In den Daten sind die Empfänger-Kontonr und Verwendungszweck drin. Die kann man dann ergänzen und eigene Infos dazuschreiben.

    Sowas wird kommen. Aber nicht 1999 als der neue Markt und Schröder und Trittin regierten und man es längst hätte machen müssen. Sondern wenn die 20-stelligen SWIFT/IBAN-Nummern Gesetz werden (2013 ?) und Handwerker ihre Rechnungen nicht bezahlt bekommen und das Geld überall landet, nur nicht wo es hinsoll.

    Die Sparkassen haben sowas auch schon. Mit Geschäftsführer und Zwischenfirma wo man sich vermutlich als Teilnehmer anmelden muss und vermutlich noch Gebühren. Also ist die Nutzung dürftig. Und viele Banken haben kein HBCI u.ä. Postbank hat FINTS dankenswerterweise mit PIN/TAN.

    In USA kann man seine Lohnschecks per Handy fotografieren und der Abwickler regelt das dann. Post oder bei der Bank einwerfen braucht man nicht mehr.

    Ein API will ich für Lastschriften. Dann kann man per Mausklick Abos abschliessen, die Kündigungsfristen, Beträge usw. zeigt die Bank einem im Onlinebanking an, man bestätigt oder lehnt ab.
    Das ist aber B2B und die Banken sind selber schuld das nicht zu machen. Dann gäbe es auch keine Abofallen mehr.

    Ein API wäre auch für Zahlungs-Aufforderungen. Wenn SAGE vom Handwerker weiss, welche KontoNr ihm das letzte Mal überwiesen hat, schickt er die Rechnung per Papier und 2-3 Tage später an die Bank (über seine Bank oder direkt) die "Zahlungs-Aufforderung" die man per Pin/Tan bestätigt wenn man das nächste Mal ins Online-Banking geht. Oder halt sofort am Handy wenn man im Hotel steht und bezahlen soll.

    Sowas würde die Effizienz massivst erhöhen und ich würde Rechnungen nicht liegen lassen, weil ich keine Lust habe, Zahlen von der vom Computer erstellten Rechnung mit bloßen Fingern ins Onlinebanking abtippen zu müssen. Dafür gibts Adelige.

    Ihr habt ja schon zugegeben das 40% (?) die Ads blockern. Fragt mal in der Abo-Abteilung wie die Zahlungs-Moral ist. Zeitdauer, Zahl der Mahnungen usw. sind relevante Kenngrößen.
    Das die QR-Codes Infos enthalten, um die Vorsteuer gleich beim Finanzamt abzubuchen, sollte klar sein. Schade das manche Finanzminister anscheinend eine Bargeld-Wirtschaft bevorzugen.

    Als Privatperson kann man sowas nicht machen. Da hat man in Diktaturen morgen kein Konto mehr. XML, MicroFormate, Payment-URLs usw. sind ja kein Problem. HR-XML ist evtl auch eine 1-Man-Show. Man würde also Standards und Testsuites definieren und jeder wäre gern dabei. Die Banken müssten nur leichte Erweiterungen oder eine Zusatz-Webseite für die Daten-Eingabe machen. Oder man öffnet das Browserfenster mit den Zahlungs-Infos und das vom Onlinebanking und der Browser fragt, ob er die Daten rüberschieben soll weil die MicroFormate auf beiden Seiten matchen. So wie bei MacOS beim Installieren durch Rüberschieben. Zahlungs-Banking-Programme wie AlfBanko usw, sind natürlich auch sofort dabei. Die Browser müssten nur eine "payment://"-Url entsprechende Handler aufrufen. Das kann das Onlinebanking sein oder AlfBanko oder Quicken oder eine Abfrage-Verzweigungs-Tool wo man einstellt mit welchem seiner Konten (Privat oder Firma) man bezahlen will. Das ist alles genau so sicher wie vorher. Man nutzt ja nicht sofortüberweisung.de oder andere Dienstleister und deren Webseiten.

    Ach übrigens: Mein Business-Case erfordert GAR KEINE Gebühren an nirgendwen. Aus die Maus. Ich brauch keine Firmen und Geschäftsführer durchfüttern. Deswegen interessiert es vielleicht auch keinen weil man dem Schwager keinen Auftrag rüberschieben kann. Hat jemand die Telefonnnummern von SAGE und AlfBanko ? Die rulen das in 4 Wochen und die anderen betteln dann, mitmachen zu dürfen.
    Schlimm genug das man bei Rezepten vermutlich bald Gebühren für den Zugriff auf die Gesundheitskarte bezahlen soll. Dann sollen die mich erst mal Bezahlen wenn ich Werbebroschüren oder Visitenkarten auf Konferenzen annehme.

    Mein Business-Case ist die Ratz-Fatz-Bezahlung und parallele Abwicklung per Finanzamt oder übertragung an DATEV und den Steuerberater.

    Antworten Teilen
  3. von Individualist am 12.12.2011 (12:13Uhr)

    Klar wäre es schön, wenn alles einheitlich wäre. Andererseits ist die Geschichte des Internet doch eine Erfolgsgeschichte der Individuallösungen.

    Entscheidender Faktor für mich ist dabei: Solange Wildwuchs besteht ist es zwar möglich, dass einzelne Lösungen Sicherheitslücken produzieren; wenn ein Service ausfällt bedeutete das dann aber noch nicht automatisch, dass alle betroffen sind. Und ja: eine API bestimmt noch nicht die unterliegende Sicherheitsarchitektur, aber sie begünstigt kollektive (Fehl-)entscheidungen.

    Ausserdem: schon heute existieren Lösungen, die den Zugriff auf eine Vielzahl von Online-Banking Portalen erleichtern und vereinheitlichen. Als Beispiel empfehle ich einen Blick auf Hibiscus/Jameica (q='hibiscus banking'). Noch dazu bleibt das Ganze für den Kunden so kostenlos.

    Schöne Grüße

    Antworten Teilen
  4. von Peterchen am 12.12.2011 (13:17Uhr)

    Das ist ja alles gut und richtig - sofern das unter "Businesscase" geschriebene auch wirklich gegeben ist :)

    Aber fehlen tut mir: wer muss denn jetzt anfangen? Oder gibt es den Kern des postulierten Verfahrens vielleicht schon?

    Antworten Teilen
  5. von Dark-Water am 12.12.2011 (13:30Uhr)

    Sehr schade das in euren Bericht die Plattform Jameica und das darauf aufbauende Plugin Hibiscus (für den Privatanwender) nicht auftaucht, So als sehr gute alternative zu den großen Playern bei Bankingsoftware

    Antworten Teilen
  6. von Peterchen am 12.12.2011 (15:38Uhr)

    @EU-Zahlungsraum: Wer will muss auch zahlen. Warum sollten Banken eine API bauen, wenn sie nichts dafür bekommen? Einen Businesscase wird es also irgendwie schon brauchen, die ganzen Server und die Software-Entwicklung kostet nämlich schon ein paar Euro ... und wenn dann mal was schiefgeht, war es auch wieder die böse Bank, die nicht sicher genug war.

    Antworten Teilen
  7. von André M. Bajorat am 12.12.2011 (15:53Uhr)

    Vielen dank für die Diskussion.
    Mir ging es hier nicht darum alle möglichen Lösungen die rund um HBCI bereits bestehen aufzulisten - egal ob Hibiscus, Subsembly oder anderen. Die im Artikel genannten Produkte oder Lösungen waren einfach nur Beispiele ohne Anspruch auf Vollständigkeit.

    Mir geht es darum, dass ich mir eine vereinheitlichte, von den Banken offiziell bereitgestellte API wünsche. Und natürlich bedarf es dann auch eines Business-Cases, der sich aber aus meiner Sicht sehr leicht darstellen lässt, wenn man das ganze von Seiten der Banken will und die Abwicklerrolle annimmt.

    @eu Zahlungsraum:
    Schöne viele Idee, die man mit einer vereinheitlichen Schnittstelle doch noch viel effektiver umsetzen kann

    @peterchen:
    Du weisst doch, dass die Bestandteile alle da sind. Man muss es nur wollen. Die Frage wird sein: Sind die Banken an der Stelle man Treiber der Lösung, oder werden sie von Dritten überholt, die dann einen Quasi-Standard schaffen.

    Antworten Teilen
  8. von Kai am 12.12.2011 (16:25Uhr)

    Vielen Dank Herr Bajorat. Ein toller Artikel der mir ein Stück weit aus der Seele spricht.

    Sehen wir uns heute in unserer Welt um, dann kommen wir um neue Geschäftsmodelle nicht herum. Die Märkte verändern sich und Rechenzentren sind in vielen Fällen nicht unbedingt als Innovationstreiber bekannt. Sie bemühen sich, aber ein guter Wille reicht eben oft nicht aus.

    Wie Sie bereits beschreiben sollte die API standardisiert sein - dies ist aber nicht gleich zu setzen mit „open for all“. Rechenzentren könnten die Entwicklung dieser API über Service- und Bereitstellungsgebühren finanzieren. Immerhin wird eine Schnittstelle nicht nur von Dienstleistern gewünscht - sondern auch von den Kunden der Rechenzentralen.

    Die Banken sehen die Rechenzentren oft als Flaschenhals und hier könnten sich alle Beteiligten etwas Entspannung verschaffen. Innovationen könnten umgesetzt werden und auch die Rechenzentren könnten von den Lösungen profitieren.

    Monopole haben heute einen schweren Stand und versucht man sie künstlich aufrecht zu erhalten verschaffen sie dem Monopolisten ein bisschen Zeit. Zumal wie beschrieben Schnittstellen bereits heute in Form von HBCI zur Verfügung stehen.

    Die Vergangenheit hat übrigens gezeigt das Innovation oftmals von anderen Branchen oder Personen in eine Branche hinein getragen werden. Vielleicht wäre über eine entsprechende API eine Möglichkeit gegeben den Bereich zu revolutionieren.

    Antworten Teilen
  9. von EU-Zahlungsraum am 12.12.2011 (16:59Uhr)

    @peterchen: Du bezahlst also dafür, QR-Links auswerten und die Webseite aufrufen zu dürfen ?

    Wieso soll ich dafür bezahlen QR-Links auswerten und mein Online-Banking automatisch auszufüllen ? Wenn die EU schlauer wäre, würde sie sogar befehlen, das alle Zettel (Rechnungen, Aufträge, Kontoauszüge,...) inhaltlich auch als QR-Code scanbar sind.

    Aber hier hat wohl noch nie jemand eine Erträgnisaufstellung in Elster reintippen müssen und sich gefragt, das das einfach nur noch total dumm ist. Wieso kann ich im Onlinebanking nicht befehlen, das die Bank die Daten ans Finanzamt schickt. Wieso kann ich Betriebsausgaben und Vorsteuer nicht im Onlinebanking markieren und automatisch ans Finanzamt schicken lassen ?

    Barcodes benutzt hier auch keiner oder nur für 1 Cent pro Barcode ? Na also.

    Und wie man an der Eurokrise mitgekriegt hat, gehts nicht um Deutschland sondern EU und andere Überweisungs-basierte Wirtschaften. USA und wohl auch England sind scheckbasiert. Wahrscheinlich haben die Schecks schon QR-Codes. Weil sie keine Überweisungen kennen und nutzen, sind die natürlich nicht an sowas interessiert.

    Man müsste einen Produzenten von Rechnungen überzeugen damit anzufangen.
    Firefox (damals noch Mozilla oder Netscape) hat die W3Cler auch nicht gefragt, ob sie Javascript oder Frames erfinden dürfen.

    Es ist auch alles egal. Wenn die 20+20-Stelligen SWIFT-IBAN-Nummern Gesetz werden, gibt es sowas dann "von selber". Obwohl Trittin es 1999 schon hätte einführen können.

    Über Web-Intents von Google geht sowas vielleicht dann auch.

    Als IT-Zwangsfreiberufler der früher mal für neue-Markt-Firmen billigst arbeiten durfte, programmiere ich lieber für meinen Vorteil als für BWLer die auf großem Fuß leben. Also was das einfach funktioniert statt Gebühren zu kosten.
    QR-Codes und Barcodes zeigen, wie man es richtig aufsetzt. Wenn die Banken nicht wollen, machen StarMoney und AlfBanko das Geschäft.

    Paypal hat komischerweise nach dem Aufkauf seine disruptive Rolle nicht fortgesetzt und das moderne Banking erfunden und durchgesetzt sondern war nur noch Ebays Payment-System. Dasselbe bei ICQ (SMS) oder Skype (Mobil-Telefonate, Auslands-Telefonate).

    Antworten Teilen
  10. von Felix am 12.12.2011 (19:09Uhr)

    Schöner Beitrag Andé! Doch ganz ehrlich ... wie lange brauchen wir noch bis zu dieser "perfekten Welt"?

    Viele Grüße
    Felix

    Antworten Teilen
  11. von André M. Bajorat am 12.12.2011 (19:28Uhr)

    felix: danke.
    technik ist da - wenn sich jemand traut sind wir kurz davor - wenn es wirklich eine lösung mit den banken sein soll (was ich für gut hielte), kommt es ein wenig auf den marktdruck an.
    lasst ihn uns zusammen aufbauen und innovationen treiben.

    Antworten Teilen
  12. von Peterchen am 12.12.2011 (19:33Uhr)

    Die Frage ist nicht, ob bezahlt wird, sondern wer bezahlt. Kein Mensch sagt, dass es der Zahlende tun soll (mal davon abgesehen, dass er das am Ende des Tages sowieso tut). Das ist auch IRL eher unüblich. Typischerweise hat irgendwer in der Prozesskette einen messbaren Vorteil. Im von Ihnen, Herr EU_Zahlungsraum (oder kennen wir uns persönlich?), angesprochenen Beispiel wäre das der Aussteller der Rechnung.

    Nochmal die Frage: warum sollte ein Marktteilnehmer (in diesem Beispiel eine Bank) irgendetwas kostenlos bereitstellen, was Entwicklungskosten verursacht und noch dazu potenziell geeignet ist, das eigene Geschäft auszuhöhlen? Gegeben: wenn ich progressiv denke kann ich mit solchen Services Kunden binden und gewinnen (wenn sie überzeugend und zu Ende gedacht sind). Blöderweise sind die Progressiven selten diejenigen, die die großen, dafür nötigen Budgettöpfe verwalten. Oder, wenn sie es dann doch tun, Riesenbammel bekommen, wenn ihnen klar wird, wie vage diese Potenziale in Euro auszudrücken sind.

    Sie äußern viele gute Ideen, z.B. gefällt mir die mit den "Belegen ans Finanzamt" - und sind wohl auch in der Lage, sowas zu programmieren - aber wer bezahlt denn Ihre Rechnung? Und die Ihrer vielen Kollegen? Auch wenn Sie billigst arbeiten: irgendwoher muss das liebe Geld kommen.

    Die Technik ist also m.E. nicht das Problem - und existiert abgesehen davon in Teilen bereits. Auch an innovativen Ideen mangelt es nicht: QR-Codes, EBPP, PFM, NFC ...

    Antworten Teilen
  13. von Albrecht am 12.12.2011 (22:36Uhr)

    Ein Wort zum Business-Case für Banken - oder besser gesagt: besteht für Banken langfristig noch ein Business-Case ohne nutzerfreundlichen API-Service? Beispiel: sobald der Arbeitgeber den Lohn auch auf Paypal überweist, der Vermieter einen Übertrag auf seinen Account erlaubt und der Händler um die Ecke das Google-Wallet akzeptiert, ist doch ein klassisches Girokonto nicht mehr notwendig. Banken wären also gut beraten, jetzt in die Zukunft zu investieren - auch wenn dies auf Kosten des kurzfristigen Erfolgs geht...

    Antworten Teilen
  14. von Phicsa am 13.12.2011 (12:04Uhr)

    In erster Linie brauchen wir Banken die nicht um 12 Uhr schließen ^^"

    Antworten Teilen
  15. von easyphil am 02.07.2013 (21:04Uhr)

    http://www.bankimport.de

    Hier ist ein Anbieter für eine browserbasierte Online-Banking-API Lösung in den Startlöchern.

    Die Beta-Phase wurde bereits gestartet. User können via HBCI (aktuell bereits funktionsfähig) und bald auch über EBICS Daten unterschiedlicher Banken einlesen und anschließend über eine standarisierte PUSH- und REST-API weiterverarbeiten. Die dargestellten Anwendungsbeispiele sind auf jeden Fall nachvollziehbar.

    Antworten Teilen
  16. von André M. Bajorat am 06.07.2013 (21:28Uhr)

    ja habe ich gesehen! gut!
    wir machen mit figo.me und der API figo connect ja etwas sehr ähnliches.

    Antworten Teilen
  17. von André M. Bajorat am 06.07.2013 (21:28Uhr)

    ja habe ich gesehen! gut!
    wir machen mit figo.me und der API figo connect ja inzwischen etwas sehr ähnliches.

    Antworten Teilen
Deine Meinung

Bitte melde dich an!

Du musst angemeldet sein, um einen Kommentar schreiben zu können.

Jetzt anmelden

Mehr zum Thema API
Gmail: Neue API erlaubt Entwicklern „coole Dinge“
Gmail: Neue API erlaubt Entwicklern „coole Dinge“

Die neue Schnittstelle, die sich noch in der Beta-Phase befindet, soll Drittanbietern als Alternative zu IMAP dienen. Gmail verspricht dadurch bessere Performance, gibt dafür jedoch nur … » weiterlesen

„Charles, die nächste API bitte!“ – So kommst du an Daten aus undokumentierten Schnittstellen
„Charles, die nächste API bitte!“ – So kommst du an Daten aus undokumentierten Schnittstellen

Nicht jeder App-Entwickler bietet eine offene, gut dokumentierte API an. Wir zeigen euch am Beispiel des Debugging-Proxies Charles, wie ihr trotzdem an die Daten kommt. » weiterlesen

Smart Home-Ideen gesucht: Nest öffnet API für Entwickler
Smart Home-Ideen gesucht: Nest öffnet API für Entwickler

Der Hardware-Hersteller startet ein Entwickler-Programm, um seine Produkte mit anderen Connected Home-Geräten zu integrieren. Als erste Partner holt sich Nest Jawbone, Logitech und IFTT. » weiterlesen

Kennst Du schon unser t3n Magazin?

t3n 36 jetzt kostenfrei probelesen! Alle Inhalte des t3n Magazins Diesen Hinweis verbergen