Hallo,

ich bin Softwareentwickler und entwickle Webanwendungen im CRM Bereich. Nun habe ich mir ein neues Projekt überlegt und ich denke ich bin hier an der richtigen Anlaufstelle.
Ich möchte ein Programm entwickeln, welches Umsätze aus den Konten der Kunden direkt in das CRM einliest und umgekehrt auch direkt welche verbuchen kann.
z.B. sollen im CRM automatisch Rechnungen als gebucht markiert werden. Oder man soll Rechnungen direkt online aus seinem CRM bezahlen können. Das würde den Kunden das Leben erleichtern.
Nun habe ich mich erst seit heute kurz mit finTS und HBCI beschäftigt und wollte Fragen, was ich mir alles anschauen muss, bzw. wie ich das ganze am besten angehe. Was für Schnittstellen gibt es für Webanwendungen? Muss ich alles selbst entwickeln oder kann ich einfach Callouts machen?

Ich freue mich über nützliche Tipps.
Danke

Zahlungsverkehr direkt online über eine Webanwendung ist nicht ohne, sicherheitstechnisch gesehen.
Hast du dir Gedanken über die damit verbundenen Risiken gemacht? Ich würde dir spontan eher empfehlen, die Schnittstelle beim Kunden laufen zu lassen und nicht im Web.

Gruß
Raimund

Hallo Raimund,

bei dem CRM handelt es sich um salesforce.com, welches Webbasiert ist und nicht beim Kunden läuft. Salesforce ist äußerst sicher, da mache ich mir keine Sorgen. Auch große Firmen wie die Deutsche Bank oder Allianz vertrauen Salesforce. Ich hoffe es ist technisch überhaupt möglich, das wäre ein Meilenstein für viele Kunden. Nun bin ich zwar Salesforce Experte, aber kenne mich im Onlinebanking-Bereich nicht aus.
Es ist übrigens möglich Salesforce auch über Java Daten zu schicken. Lässt sich da vielleicht etwas machen? Ansonsten stehen einem die SOAP und die REST Api zur Verfügung.

Ich habe bereits gesehen es gibt einen Anbieter für eine Javascript Schnittstelle, was an sich auch denkbar wäre.

Bevor Du auf technischer Ebene weiter machst, müßtest Du wohl eher erst mal die juristische Seite abklären! Entweder der Kunde muß Dir seine eigenen Zugangsdaten aushändigen, zur Hinterlegung auf diesem Webserver. Dies ist aber in den AGB sämtlicher Banken absolut verboten. Der Kunde darf seine Daten nur auf entsprechenden Seiten der Bank eingeben...

Alternativ müßte der Kunde Dir/dem Anbieter - in jedem Falle aber einer natürlichen Person! - eine Bankvollmacht erteilen. Entweder zum Abruf der Umsätze oder gar zum Senden von Zahlungsaufträgen. Erstens kann ich mir nicht vorstellen, dass viele Kunden das tun würden und zweitens wäre die "Last" auf den Schultern der entsprechenden natürlichen Person schon sehr groß. Wenn doch mal irgendwas passiert und über die Kontovollmachten Gelder überwiesen werden, wäre wohl diese natürliche Person voll haftbar - ggf. für Unmengen von Kundenkonten. Auch dies erscheint mir nicht machbar.

Eine Alternative wäre, dass man den Weg als "Servicerechenzentrum" geht. Dies wird von Rechenzentren genutzt, die z.B. Gehaltsabrechnungen erstellen. Diese (z.B. DATEV) erstellen die Gehaltabrechnungen und die nötigen Überweisungsdateien dazu. Nach entsprechender Freischaltung können sie diese Zahlungsdatei dann auf die div. Bankrechner hochladen aber NICHT freigeben. Dies macht der Kunde selbst. Möglich ist hier z.B., dass die bereitstehende Datei dem Kunden in seinem Webbanking (also auf der Seite der Bank!) angezeigt wird und dieser sie dann durch Eingabe einer TAN freigeben kann. In deinem Fall könnte Deine Software die Zahlungen erzeugen und auf die Bank des Kunden hochladen und der Kunde gibt dann den Sammler frei. Somit liegt die Hoheit über sein Konto und auch das Risiko beim Kunden selbst.

Weiterhin ist es auch möglich, auf diesem Weg Umsätze abzurufen, wenn man dafür entsprechend freigeschaltet wird. Auch das macht z.B. die DATEV, um diese Umsätze direkt in gehostete Buchhaltungen von Steuerberatern zu übernehmen.

Ich denke, dass so ein Weg für Dich geeignet wäre.

Aus meiner Sicht kommt auch nur die RZ-Lösung in Form von Umsatzabruf nach dem Beispiel von Datev (dafür müsste Salesforce - analog Datev - mit allen in Frage kommenden Rechenzentren eine RZ-Vereinbarung abschliessen, z.B. GAD, Fiducia, FI, DeuBa, CoBa usw. und jeder einzelne Kunde müsste dann bei seiner Bank eine Umsatzlieferung über RZ beauftragen, das sind Standard Prozesse) in Frage oder - wenn überhaupt - ein EBICS T-User. Bei EBICS hat man i.d.R. kein juristisches Problem, denn die Vereinbarung wird zwischen Firma und Bank getroffen, Teilnehmer sind quasi separates Beiwerk. EBICS hat jedoch den Nachteil, dass Banken häufig dafür separate Gebühren vereinnahmen.

Bei FinTS sehe ich - genau wie msa - in der Tat das Problem, dass sämtliche denkbare Konstrukte (mal ganz abgesehen davon, ob man nur Umsätze abholt oder auch Aufträge schickt) aufgrund der Teilnahmevereinbarung für das Onlinebanking mit der Bank ausscheiden. Und den Endkunden von Seiten Salesforce zu einer "unsauberen" Krücke zu verleiten/nötigen würde den Ruf von Salesforce mit Sicherheit nicht günstig beeinflussen. Oder was wollt ihr dem Kunden sagen, wenn er euch fragt, ob er euch die Zugangsdaten überhaupt geben darf? Und wenn er es nicht tut bekommt er keine Lösung angeboten, denn eine Teilnahmevereinbarung in FinTS kann niemals auf Salesforce lauten sondern muss immer eine natürliche Einzelperson (also im Zweifel ein einzelner Mitarbeiter von Salesforce, der seine Zugangsdaten aber rein vertraglich auch nicht hergeben darf!) sein. Ist ja auch nicht das gelbe vom Ei, oder?

Unterm Strich kann man sagen, FinTS ist für solche Automationen schon aus rein vertraglicher Sicht denkbar ungeeignet. Und bis auf ein paar einzelne Details ist das auch - soweit ich weiß - die einzige Gemeinsamkeit bei ALLEN Banken, die FinTS anbieten

Oder man wählt den klassischen Ansatz vieler anderer CRM/ERP Lösungen:

Umsatzimport über das Format CAMT5X oder SWIFT MT94X und Zahlungsexport über eine enstprechende SEPA pain Variante...

Das "Datenschleudern" obliegt dann dem Kunden mit seiner OB-Lösung...HBCI/FinTS oder EBICS oder Web-Banking... je nach Bank
und Kundenanforderung... In die gängingen Lösungen lassen sich dann die Zahlungen importieren oder zum Versenden einlesen und
diese stellen dann auch die Umsatzdaten bereit für den Import im CRM-Tool.

Od

Danke erstmal für die Antworten.

Also dass die Zugangsdaten des Kunden in Salesforce nicht gespeichert werden dürfen ist mir jetzt klar. Das ist ja rechtlich verboten.
Und den Weg mit den Rechenzentren habe ich so verstanden: Meine Software erstellt, bzw. importiert entsprechende Überweisungsdateien. Sie lädt sie auf den Server der Bank hoch und der Kunde kann sie dann in seinem Onlinebanking durch Eingabe eine Tan tätigen.
Andersrum könnte ich aber Umsätze abrufen, ohne Einwirkung vom Kunden, das ganze soll ja automatisch passieren, richtig?
Was für Technologien stecken dahinter und was muss ich alles Wissen um so etwas anzugehen?

Die SRZ Lösung hast du zutreffend beschrieben. Technisch kann das Ongum oder EBICS sein. Kommt auf das RZ an. Musst du bei den RZ's mal nachfragen, was die heutzutage benutzen. Wenn es sich auf wenige Banken konzentriert könnt ihr auch mit den Banken direkt sprechen. Manchmal werden auf diesem Wege auch EBICS Vereinbarungen getroffen, um den Weg über die RZ zu ersparen, der manchmal etwas mühsam ist.

Übrigens ist es nicht verboten, Zugangsdaten zu speichern - im Sinne von Strafrecht - sondern es widerspricht den Nutzungsbedingungen. Damit handelt der Teilnehmer grob fahrlässig und die Standard Haftung der Bank nach PSD ist in Gefahr. Kleiner aber wesentlicher Unterschied.

Gibt es einen Unterschied zwischen Geschäfts und Privatkunden, was das speichern der Nutzerdaten angeht?

Nein. Zugangsdaten sind in beiden Fällen immer höchstpersönlich. Ausnahme ist der sog. "technische Teilnehmer" bei EBICS, der für automatische maschinelle Übertragungen (sowohl Umsätze von Bank zu Kunde als auch Zahlungsvorgänge von Kunde zu Bank) vorgesehen ist. Dieser technische Teilnehmer hat allerdings keine Unterschriftsberechtigung.

Hintergrund ist, dass die Bank immer eine Person benennen können muß, die eine Zahlung getätigt hat. Erstens schon im eigenen Interesse (wer ist verantwortlich, dass das Geld weg ist) und zweitens auch z.B. Behörden gegenüber (Geldwäsche ect..). Somit muß ein Zugang mit Unterschriftsberechtigung immer einer natürlichen Person ausgestellt werden. Einen technischen Teilnehmer gibt es bei HBCI übrigens nicht.

msa's Antwort ist an sich schon richtig. Aber zur Sicherheit: Was meinst du genau mit "Nutzerdaten"? Es gibt im Bankgewerbe schon etliche Unterschiede, man nennt es hier aber Verbraucher und Nichtverbraucher, definiert durch § 13 BGB.
Daher meine Bitte: Bitte konkretisiere deine Frage, damit wir sicher gehen, was du meinst. Wenn es sich auf Zugangsdaten zu elektr. Medien bezieht muss man zusätzlich zur Unterscheidung nach § 13 auch noch eine Unterscheidung nach Verfahren machen. Die Verträge und Bedingungen bei FinTS sind i.d.R. immer anders gestaltet als die bei EBICS. Und sie sind nicht bei allen Banken identisch formuliert. Häufig sind es Verbandsvordrucke.
EBICS ist von seiner Ausgestaltung her schon eher auf Automatisierung bedacht. Hier gibt es den T-User wie von msa beschrieben. Dieser ist natürlich typischerweise dafür vorgesehen, dass seine Zugangsdaten elektr. gespeichert werden, sonst wäre eine Automation unmöglich. Hier würde man also sagen, ist erlaubt. Bei FinTS hingegen ist das hingegen bei keiner Benutzerart erlaubt.