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.