Implementierung von Zahlungsdaten & -aufträgen in eine externe Anwendung

Welche Schnittstelle bei welcher deutschen Bank ist praktikabel?

 
DIR
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 5
Dabei seit: 01 / 2014
Betreff:

Implementierung von Zahlungsdaten & -aufträgen in eine externe Anwendung

 · 
Gepostet: 27.01.2014 - 15:07 Uhr  ·  #1
Hallo allerseits,

mein Name ist David und ich arbeite derzeit als PM an der Implementierung von Zahlungsdaten & -aufträgen (eingehende & ausgehende SEPA-Überweisungen) in eine rein webbasierte Applikation (PHP) für das Management von Freelancer Aufträgen (keine Online-Banking Anwendung). Die Integration soll die “Rohdaten” direkt in unserer Webapplikation bereitstellen und Zahlungen direkt aus dieser Applikation abwickeln. Da dieses Forum offenbar das einzige im deutschsprachigen Raum ist, in dem sich Kompetenz in diesem Bereich findet würde ich gern ein paar Fragen dazu stellen.

Um das Matching von eingehenden Zahlungen zu existierenden Vorgängen sicherzustellen werden möglichst viele bzw. alle zur Überweisung verfügbaren Daten (Währung, Betrag, Name, Adresse, Verwendungszweck, IBAN, BIC/SWIFT, Bank, Bankadresse, usw.) innerhalb unserer Applikation benötigt. Zudem müssen Auszahlungen automatisiert an eine Bank übergeben und abgewickelt werden. Aus diesen Anforderungen folgende Fragen:

1. Welches Verfahren bzw. welche API ist für diese Anforderungen am besten geeignet (FinTS, EBICS, Alternativen)?

2. Offensichtlich gibt es erhebliche Unterschiede zwischen den von den einzelnen Banken zur Verfügung gestellten APIs. Welche deutsche Bank bietet die umfangreichste, stabilste & zuverlässigsten Schnittstellen?

3. Die üblichen “Privatbanking” Authentifizierungsmethoden (PIN/TAN, Chipkarte, Datei) sind für unseren Fall nicht praktikabel. Ideal wäre natürlich etwas wie OAuth 2.0, aber dies scheinen die vorhandenen Schnittstellen nicht zu unterstützen. Gibt es etwas vergleichbar praktikables?

Vielen Dank für Eure Hilfe,

David
Benutzer
Avatar
Geschlecht:
Beiträge: 3338
Dabei seit: 05 / 2013
Betreff:

Re: Implementierung von Zahlungsdaten & -aufträgen in eine externe Anwendung

 · 
Gepostet: 27.01.2014 - 15:57 Uhr  ·  #2
Hallo David,
bankseitig gibt es in D nur zwei Schnittstellen/Verfahren: FinTS (früher HBCI) und EBICS. Apis stellen Banken nicht zur Verfügung. Im Low Budget Markt gibt es derzeit keine Weblösung. Ich vermute allerdings, dass sich in Unixoiden Umgebungen einige Leute den hbciServer von Olaf Willuhn basierend auf Java "verbogen" haben, um die Aufgabe zu erledigen. In .NET/C++/Win Umgebungen wäre die Subsembly FinTS und EBICS Api eine sehr empfehlenswerte Alternative.
Für welches System soll es denn sein?

Die Frage ob FinTS oder EBICS ist zum einen eine Kostenfrage, weil viele Banken nur FinTS kostenfrei anbieten und für EBICS Geld nehmen und zum anderen eine Verfügbarkeitsfrage. Denn EBICS anzubieten haben sich die deutschen Banken selbst verpflichtet. Bei FinTS ist das nicht so. Weiterhin ist es eine Frage der Authentifizierung. Hier empfehle ich unbedingt EBICS, weil man damit für alle Banken nur eine Unterschriftsdatei und somit ein Passwort hat und nicht soviele wie man Banken bedient.
Benutzer
Avatar
Geschlecht:
Beiträge: 3338
Dabei seit: 05 / 2013
Betreff:

Re: Implementierung von Zahlungsdaten & -aufträgen in eine externe Anwendung

 · 
Gepostet: 27.01.2014 - 16:05 Uhr  ·  #3
msa
Benutzer
Avatar
Geschlecht:
Herkunft: München
Alter: 55
Beiträge: 3937
Dabei seit: 03 / 2007
Betreff:

Re: Implementierung von Zahlungsdaten & -aufträgen in eine externe Anwendung

 · 
Gepostet: 27.01.2014 - 16:10 Uhr  ·  #4
Generell mußt Du das nehmen, was die Kreditwirtschaft zur Verfügung stellt. Und da gibt es nur HBCI/FinTS und EBICS. Das ist sozusagen eine Frage von "Friß oder stirb". Keine Bank wird wegen irgendwelcher Vorgaben eines Kunden irgendwelche neuen Entwicklungen tätigen.

1) Ob HBCI oder EBICS ist hauptsächlich eine Frage der Mengen, die darüber verarbeitet werden sollen. Wenn es ein paar Zahlungen täglich sind, ist EBICS sicher oversized, wenn es zehntausende oder gar hunderttausende am Tag sind, dann ist EBICS das einzig Sinnvolle. Weiterhin sind bei den beiden Wegen die Kosten unterschiedlich. HBCI ist "eher Privatkundenweg", somit in den meisten Fällen ohne extra Kosten verfügbar, EBICS ist "eher Großkundenweg" und somit Gebührenpflichtig. Auch muß man berücksichtigen, dass HBCI ein "Dialogverfahren" ist, das heißt, es stehen Informationen eher zur Verfügung und Zahlungsaufträge werden je nach Bank in Echtzeit gebucht. EBICS beruht auf Dateiübertragung. Die Dateien mit den Informationen müsen von der Bank erst bereitgestellt werden, die eingereichten Dateien mit Zahlungsaufträgen erst Batchmäßig verarbeitet werden.

2) Es wird branchenweit EBICS zur Verfügung gestellt (Selbstverpflichtung), HBCI stellen eigentlich alle Geschäftsbanken bereit, nur div. Direktbanken sparen sich das und wollen Kunden auf die Website zwingen. Innerhalb von EBICS und HBCI unterscheiden sich die Schnittstellen nur dadurch, welche Geschäftsvorfälle angeboten werden und welche nicht. Das ist von Bank zu Bank sehr unterschiedlich. Allerdings werden Umsatzabfrage und SEPA-Überweisung von allen unterstützt. Unterschiede gibts schon wieder dabei, ob nur Einzelüberweisungen oder auch Sammelüberweisungen (eine Buchung auf dem Auszug) unterstützt werden. Auch muß man berücksichtigen, dass alle Banken die Standards wieder etwas anders interpretieren und somit kundenseitig Anpassungen nötig sind. Vor diesem Hintergrund ist die technische Programmierung hochkompliziert und erfordert eine Unmenge an Spezalwissen. Das Rad neu zu erfinden ist somit eigentlich nicht ein gangbarer Weg. Um das zu sparen gibt es eine Reihe von Softwarewerkzeugen, bei denen der Programmierer die Wege nur NUTZT, in Form von APIs. Eine Adresse hierfür ist http://www.subsembly.com . Hier gibt es für verschiedene Arten der Implementierung div. Werkzeuge zu lizenzieren. Sowohl für HBCI als auch für EBICS.

3) Als Authentifizierung gibt es nur die Wege, die die Branche anbietet. Das sind bei HBCI div. TAN-Verfahren, Chipkarten und Schlüsseldatei. Schlüsseldatei wäre durchaus ein gangbarer Weg. Chipkarten sind hier eigentlich nur eine andere Form der Schlüsseldatei (Schlüssel auf der Chipkarte gespeichert). Lediglich die Sparkassen bieten hier NUR Chipkarten an, keine Schlüsseldatei. Somit ist HBCI via Sparkasse für Vollautmatismus nur eingeschränkt nutzbar. Bei EBICS wird eine elektronische Unterschrift genutzt, welche wahlweise als Datei gespeichert wird (USB-Stick, gesichertes Netzlaufwerk ect.) oder auf einer Chipkarte sitzt. Bei EBICS ist es auch möglich, sog. technische Teilnehmer einzurichten, die NUR Daten übertragen, Freigabe erledigt dann ein menschlicher Teilnehmer im Dialog mit dem Bankrechner. Auch sind via EBICS Gemeinschaftszeichnung und weitere Dinge möglich.

Alles in Allem ein hochkomplexes Thema. Der Weg, sich eine Bank nach den technischen Möglichkeiten auszusuchen ist fast nicht möglich, bei einem solchen Projekt sollte man sich wohl erst eine Bank aussuchen und dann mit den dortigen Elektronic Banking Spezialisten sprechen. Wobei der Weg auch schwierig ist. Diese werden wohl eher das von der Bank angebotene fertige Softwareprodukt pushen und können sicher keine Hilfestellung bei Eigenentwicklungen bieten.
Benutzer
Avatar
Geschlecht:
Beiträge: 3338
Dabei seit: 05 / 2013
Betreff:

Re: Implementierung von Zahlungsdaten & -aufträgen in eine externe Anwendung

 · 
Gepostet: 27.01.2014 - 16:15 Uhr  ·  #5
msa, sehr gut geschrieben, die Konsequenz zu Sub zu verlinken wußte ich :)
Aber: Du solltest auch bedenken, dass EBICS nicht nur bei einer Vielzahl von Zahlungen sondern auch bei einer Vielzahl von Banken enorme Erleichterung bringt, weil man nur eine elektr. Unterschrift für alle Banken hat! Nachteil, wenn man sich sperrt, muss man die Ini auch bei allen neu machen :(

Und was ich noch hervorheben will: Wenn jemand Zahlungseingänge in Neartime braucht ist EBICS ungeeignet. Denn bei EBICS bekommt man immer nur die Umsätze vom Vortag. Untertägige Umsätze in Form von Vormerkposten (VMK) werden von jeder Bank anders zur Verfügung gestellt, wenn überhaupt.
Also David, mit einem konkreten Anforderungsprofil und vor allem einer Liste der Banken könnte man dir besser helfen. Das ist mein Lieblingsthema :)
DIR
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 5
Dabei seit: 01 / 2014
Betreff:

Re: Implementierung von Zahlungsdaten & -aufträgen in eine externe Anwendung

 · 
Gepostet: 27.01.2014 - 16:36 Uhr  ·  #6
Hallo onlbanker & MSA,

vielen Dank zunächst für die schnelle Hilfe & die weitreichenden Ausführungen. Dies hat mich jetzt weitergebracht als wochenlange Recherche & Diskussionen mit den "Experten" bei den Banken. Ich würde aber doch noch mal gern auf das Thema "Wahl der Bank" kommen: Wir sind derzeit in der schönen Lage uns für DE noch eine Bank wählen zu können. Gibt es hier irgendwelche Erfahrungswerte welche Banken und deren Schnittstellen technisch fit und "kooperativ" sind?

Vielen lieben Dank,

David
Benutzer
Avatar
Geschlecht:
Beiträge: 3338
Dabei seit: 05 / 2013
Betreff:

Re: Implementierung von Zahlungsdaten & -aufträgen in eine externe Anwendung

 · 
Gepostet: 27.01.2014 - 16:39 Uhr  ·  #7
Achso, es geht nur um eine Bank? Dann auf jeden Fall FinTS nehmen und eine Bank mit Direktverbuchung wählen. Da kommen alle Sparkassen außer Hamburg sowie alle GAD Volks- und Raiffeisenbanken in Frage, bei Fiducia Banken weiß ich nicht genau wie das läuft. Die sog. "Großbanken" und Direktbanken haben im ZV alle irgendwelche merkwürdigen Schwächen über die man sich ewig nur ärgert.
DIR
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 5
Dabei seit: 01 / 2014
Betreff:

Re: Implementierung von Zahlungsdaten & -aufträgen in eine externe Anwendung

 · 
Gepostet: 27.01.2014 - 16:55 Uhr  ·  #8
Ja, im ersten Ausbauschritt reicht eigentlich eine Bankverbindung mit mehreren Konten (allerdings in verschiedenen Währungen). Die Zahl der Transaktionen ist jedoch recht gross (6-7 stellig p.m.). Weiterhin müssen Zahlungen international (praktisch weltweit) getätigt werden.
Benutzer
Avatar
Geschlecht:
Beiträge: 3338
Dabei seit: 05 / 2013
Betreff:

Re: Implementierung von Zahlungsdaten & -aufträgen in eine externe Anwendung

 · 
Gepostet: 27.01.2014 - 16:58 Uhr  ·  #9
AAAAHH! Stop, wenn AZV im Spiel ist kommen die Großbanken doch wieder ins Spiel und FinTS vergessen wir bei den Mengen auch mal schnell! Die Großbanken haben häufiger Korrespondenten in den Ländern sitzen und können dadurch billiger abwickeln. Und bei diesen Mengen ist es ein reine Preisfrage. Also Hausaufgabe: Mengengerüst pro Land erstellen (dabei SEPA und nicht SEPA unterscheiden) und Angebote einholen bei Deutsche, Commerz, den großen Landesbanken und vielleicht noch die ein oder andere intern. tätige Direktbank mit deutscher Niederlassung mit EBICS Bankrechner wie z.B. Cortal Consors.
Benutzer
Avatar
Geschlecht:
Beiträge: 3338
Dabei seit: 05 / 2013
Betreff:

Re: Implementierung von Zahlungsdaten & -aufträgen in eine externe Anwendung

 · 
Gepostet: 27.01.2014 - 17:42 Uhr  ·  #10
Zitat geschrieben von DIR
Die Zahl der Transaktionen ist jedoch recht gross (6-7 stellig p.m.).

Das hat mir auch noch keine Ruhe gelassen. Bist du sicher, dass du und wir von der gleichen Einheit reden? Wir reden von Buchungsposten am Konto. Bei 7stellig wären das um die 50.000 pro Werktag und über 2.000 pro Stunde!!! Bist du wirklich sicher, dass es soviele Buchungen geben wird? Das wäre ja schon ein eigener kleiner Bankbetrieb.
Wie werden die denn jetzt abgewickelt?
DIR
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 5
Dabei seit: 01 / 2014
Betreff:

Re: Implementierung von Zahlungsdaten & -aufträgen in eine externe Anwendung

 · 
Gepostet: 27.01.2014 - 18:19 Uhr  ·  #11
Du hast recht, ich habe mich tatsächlich um eine Stelle vertan. Die Implementierung muss für 20.000-200.000 eingehende und bis zu 50.000 ausgehende Zahlungen p.m. ausgelegt werden.
Benutzer
Avatar
Geschlecht:
Beiträge: 3338
Dabei seit: 05 / 2013
Betreff:

Re: Implementierung von Zahlungsdaten & -aufträgen in eine externe Anwendung

 · 
Gepostet: 27.01.2014 - 18:27 Uhr  ·  #12
OK, aber das ist mit 1.000 bis 10.000 pro Werktag auch noch eine nennenswerte Menge. Bleibt die Hausaufgabe des Mengengerüsts unterschieden nach Korrespondenzländern und ob SEPAfähig oder nicht fähig. ACHTUNG: Es gibt Länder die keinen Euro haben und trotzdem SEPAfähig sind. Und dann Angebote einholen. Das ist bei diesen Mengen kein technische sondern in erster Linie ein kaufmännische Frage. Um die Technik kümmerst du dich zusammen mit dem Abwickler, wenn du dafür den günstigsten gefunden hast.
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 140
Dabei seit: 02 / 2004
Betreff:

Re: Implementierung von Zahlungsdaten & -aufträgen in eine externe Anwendung

 · 
Gepostet: 28.01.2014 - 14:22 Uhr  ·  #13
Wenn kostenseitig vertretbar, würde ich an dieser Stelle noch einen direkten SWIFT-Anschluss z.B. über einen Concentrator in Spiel bringen. Könnte sich durchaus in der Kosten/Nutzen-Betrachtung rechnen.
DIR
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 5
Dabei seit: 01 / 2014
Betreff:

Re: Implementierung von Zahlungsdaten & -aufträgen in eine externe Anwendung

 · 
Gepostet: 28.01.2014 - 17:32 Uhr  ·  #14
Vielen lieben Dank schon mal für alle wirklich hilfreichen Ausführungen & Hinweise! Ich befürchte, ich werde mich demnächst noch mal mit ein paar Fragen melden müssen.

Danke,

David
Benutzer
Avatar
Geschlecht:
Beiträge: 3338
Dabei seit: 05 / 2013
Betreff:

Re: Implementierung von Zahlungsdaten & -aufträgen in eine externe Anwendung

 · 
Gepostet: 29.01.2014 - 06:48 Uhr  ·  #15
Gerne, kannst dich jederzeit melden. Spannendes Thema!
Benutzer
Avatar
Geschlecht: keine Angabe
Herkunft: Im wunderschönen Ahrtal
Beiträge: 2077
Dabei seit: 04 / 2004
Betreff:

Re: Implementierung von Zahlungsdaten & -aufträgen in eine externe Anwendung

 · 
Gepostet: 29.01.2014 - 09:43 Uhr  ·  #16
Zitat

Stop, wenn AZV im Spiel ist kommen die Großbanken doch wieder ins Spiel und FinTS vergessen wir bei den Mengen auch mal schnell! Die Großbanken haben häufiger Korrespondenten in den Ländern sitzen und können dadurch billiger abwickeln.

Das ist bis auf den Punkt "FinTS vergessen" schlicht Unsinn. Sowohl die Sparkassen als auch die Genossen können AZV midestens genausogut wie meine staatsgetützte Lieblings"bank". Natürlich haben weder die Sparkasse noch die Voba Vordertupfingen einen eigenen SWIFT-Anschluss. Den brauchen sie aber auch nicht, weil sie mit ihren Zentralen (Landesbanken bzw. WGZ kooperieren). Es werden sich bei den lokalen Banken auch eher Leute finden, die wissen wen die fragen müssen, als im Großbankvertriebspunkt in der nächsten Großstadt. Deren Fachleute sitzen nämlich im allgemeinen entweder in einem Callcenter oder an einem bis wenigen zentralen Standorten bundesweit.

PS: Auch unsere Beraterinnen sind hübscher als die Blonde aus dem seltsamen Werbespot! :love: 8-)
Benutzer
Avatar
Geschlecht:
Beiträge: 3338
Dabei seit: 05 / 2013
Betreff:

Re: Implementierung von Zahlungsdaten & -aufträgen in eine externe Anwendung

 · 
Gepostet: 29.01.2014 - 10:41 Uhr  ·  #17
Fellini, du musst mal richtig lesen, bevor du mit deinen Kraftausdrücken um dich wirfst! Ich habe nicht gesagt, dass Volksbanken und Sparkassen deshalb ausscheiden oder dies schlechter machen sondern das die Großbanken durch Korrespondenden, eigene SWIFT Anschlüsse etc. häufig billiger abwickeln können. Reine Preisfrage, darauf lag die Betonung!
Wie häufig weiß ich natürlich nicht, weil ich weder weiß um welche Zielländer es geht noch wie die Konditionen im einzelnen sind. Aber große Banken (vor allem internat. tätige) haben nun mal andere Möglichkeiten im AZV. Und das ist kein Unsinn. Ich möchte dich bitten, das zurück zu nehmen!
Benutzer
Avatar
Geschlecht: keine Angabe
Herkunft: Im wunderschönen Ahrtal
Beiträge: 2077
Dabei seit: 04 / 2004
Betreff:

Re: Implementierung von Zahlungsdaten & -aufträgen in eine externe Anwendung

 · 
Gepostet: 29.01.2014 - 13:03 Uhr  ·  #18
Ich kenne nicht die internen Strukturern der Großbanken. Ich kann mich kundenseitig aber an keinen Fall erinnern, wo wir bei einem Angebot der Großbanken nicht mindestens ähnliche Konditiionen bieten konnten. Sowohl in Regel- als auch in Sonderkonditionen. Deswegen hast Du Recht damit, dass Großbanken u.U billiger abwicklen könnten. Was ich sagen wollte: Von diesem Preisvorteil muss nicht zwingend etwas beim Kunden ankommen.
Da billig nicht alles ist:
Bezüglich des angebotenen Service und der vorhadenen Fachkompetenz habe ich in einigen Praxisjahren im EB bei allen Bankengruppen extrem gute und extrem schlechte Kollegen (und alles dazwischen) erlebt. Tendenziell fühlte ich mich aber bei den lokalen Instititen wegen der meist vohandenen Nähe zum Kunden besser augehoben. Wie gesagt: Mein höchst subjektiver Eindruck.
Benutzer
Avatar
Geschlecht:
Beiträge: 3338
Dabei seit: 05 / 2013
Betreff:

Re: Implementierung von Zahlungsdaten & -aufträgen in eine externe Anwendung

 · 
Gepostet: 29.01.2014 - 13:06 Uhr  ·  #19
OK, Entschuldigung angenommen.
Aber wie oft musstest du eine Kondition für zwischen 1.000 bis 10.000 (!!!) Posten pro Werktag nennen? Selbst wenn nur die Hälfte davon AZV ist ist das m.E. für einen einzigen Kunden eine beachtliche Menge.
Ich weiß es auch nicht definitiv aber ich denke, bei den Mengen machen sich auch winzigste Preisunterschiede sehr bemerkbar. Das war im Grunde alles, was ich zu bedenken geben wollte.
Gewählte Zitate für Mehrfachzitierung:   0