Hallo zusammen,

ich nutze mit einem Zweitbenutzer SFirm 4 ( Patch 21.08 / Build 4283 vom 10.08.2021) als
Serverinstallation mit zusätzlichen Clientinstallationen.

Hier werden von zwei verschiedene Banken Überweisungen im zweistufigen Unterschriftsverfahren genutzt.

Beide Nutzer haben A-Vollmachten und haben Vollzugriff in SFirm und nutzen bei beiden Banken das PIN/TAN-Verfahren unter Einsatz eines physischen TAN-Generators und Bankkarte.

Bei Bank1 (Sparkasse) funktioniert das reibungslos, bei Bank2 (Volksbank) gibt es hingegen Probleme mit dem Verfahren.

Wie wird bei Bank1 vorgegangen, wo alles funktioniert:

1) Überweisungsauftrag von Arbeitsstation des Nutzers A wird "ausgegeben"
2) Es öffnet sich das Formular "Versand SEPA XML", wo dann unter "elektronische Unterschrift" die Rollen der Benutzer
festgelegt werden können.
3) Nutzer A wählt dann sich selbst als "ausführend" und Nutzer B als "beteiligt"
4) "Ausführen"
5) Es öffnet sich das Fenster zur Authentisierung von Nutzer A, wo er die PIN eingeben muss
6) Nach Eingabe öffnet sich das Fenster zur TAN-Eingabe/Generierung
7) Nach Eingabe der TAN öffnet sich ein Fenster des SFAutomat 4.x, wo gefragt wird, ob man die TANs der weiteren
beteiligten Benutzer jetzt oder später einreichen möchte

Info: Klickt man auf "Jetzt", erfolgt wieder die Authentisierung und TAN-Eingabe/Generierung an der gleichen Arbeitsstation. Das möchte man aber ja nicht unbedingt, da der zweite Benutzer ja an einer anderen Arbeitsstation sitzt.

8.) Daher wählt Nutzer A jetzt "Später"
9) Auf dem Homescreen der Arbeitsstation von Nutzer B erscheint jetzt der Hinweis, dass es offene Aufträge gibt, wo er gefordert ist eine TAN-Eingabe vorzunehmen.
10) Führt er die Einreichung durch, wird der Auftrag/Überweisung korrekt ausgeführt und ein Ausgabeprotokoll gedruckt.


Das Problem bei Bank2 ist jetzt aber, dass bei sonst gleichem Ablauf bei der Arbeitsstation von Nutzer A der
Schritt 7) komplett von SFirm übersprungen wird und SFirm direkt verlangt, dass die Authentisierung des zweiten Benutzers
von der gleichen Arbeitsstation ausgeführt wird. Das ist natürlich ein Problem, da ja nicht Sinn und Zweck ist, dass der Nutzer B zur Arbeitsstation von Nutzer A läuft.

Wenn die Authentisierung aber an der gleichen Arbeitsstation durchgeführt wird, wird der Auftrag/Überweisung von der Bank ausgeführt.

Hinweis hierzu:

Wenn sich Nutzer B an der gleichen Arbeitsstation von Nutzer A authentisieren soll und dann "Abbrechen" gewählt wird, wird ohne weitere Nachfragen ein Ausgabeprotokoll gedruckt und der Auftrag in S-Firm als "abgeschlossen" markiert und gelöscht, obwohl die Überweisung nicht von der Bank ausgeführt wird, da ja eine Zweitunterschrift fehlt.

Laut der Bank liegt es SFirm, da bei denen "alles richtig" hinterlegt sein soll, laut SFirm liegt es an der Bank. Wir kommen hier leider gar nicht weiter.

Hat hierzu jemand eine Idee?

oft ist es sinnvoll bei Problemfällen soviel Details wie möglich zu liefern
... bspw. die Banken/Sparkassen bzw. das Rechenzentrum

Doppelzeichnung per HBCI bieten nur sehr wenige Banken/Rechenzentren an. Ich gehe davon aus, dass deine zweite Bank das über HBCI garnicht anbietet! Da wirst Du wahrscheinlich EBICS nutzen müssen. HBCI ist eher für die Privatkundenschiene vorgesehen, wo solche Anforderungen so gut wie nicht vorkommen. Bei EBICS ist das anders, das ist für Geschäftskunden vorgesehen und deswegen gibt es da Doppelzeichnung natürlich.

Dass SFIRM "die Schritte überspringt" ist auch ein Indiz dafür, dass die Bank das in der BPD nicht liefert. Und SFIRM macht natürlich nur das, was der Bankrechner anbietet.

Ich denke eher, das SFirm mit der Bankverbindung die Weiterleitung an einen anderen Arbeitsplatz nicht hinbekommt. Das ist aber ein internes Feature von SFirm. Bei Profi cash müßen beide Zeichnenden zwingend beim Sendevorgang am gleichen Rechner die Autorisierung durchführen. Deshalb ist das bei Nutzung über Programm ja auch keine wirklich sinnvolle Herangehensweise.
Der Vorschlag von msa bzgl. EBICS ist tatsächlich die sinnvollste Herangehensweise, auch wenn die meisten Banken für so einen Zugang zusätzliche Gebühren erheben.

Bank1 (wo es funktioniert) = Sparkasse
Bank2 (wo es nicht funktioniert) = Volksbank

Wie ich das Rechenzentrum herausfinde, weiß ich leider nicht. Ich weiß nur, dass die Volksbank das Rechenzentrum Fiducia nutzt.

Also die Doppelzeichnung per HBCI ansich funktioniert ja.

Nur eben nicht Erstunterschrift an Arbeitsstation Nutzer A und Zweitunterschrift an Arbeitsstation Nutzer B.

Es geht bei Bank2 (Volksbank) nur, wenn die Authentisierung am gleichen Arbeitsplatz sequentiell erfolgt und direkt zum Abschluss gebracht wird.

Bei Bank 1 (Sparkasse) geht es auch von unterschiedlichen Arbeitsstationen aus. Dabei ist es nicht schädlich, wenn Erstunterschrift um 06:00 Uhr und Zweitunterschrift um 19:00 Uhr gegeben wird. Erst wenn die Zweitunterschrift auch vorliegt, bringt S-Firm den Vorgang zum Abschluss.

@TS1
Die Sparkassen bieten als Einzige bereits PushTAN 2.0 an. Nur damit ist das möglich. Die Volksbanken planen sowas, haben es aber noch nicht umgesetzt. Somit gilt für beide Banken: Works as designed.

Na da haben wir es doch schon. Beim Sparkassenrechenzentrum FI ist es möglich, die Unterschriften (TANs) EINZELN nacheinander zu übermitteln. Beim Volksbank-Rechenzentrum Fiduza geht das nicht, da müssen beide TANs im GLEICHEN Sendevorgang miteinander übertragen werden.

Es handelt sich um ein Feature, das vom Bankrechner angeboten werden muss, sonst kann es nicht klappen. Hintergrund ist, dass eine TAN ja nur eine bestimmte Zeit gültig ist. Wenn SFIRM diese erste TAN intern zwischenspeichern würde (was sicherheitstechnisch eh problematisch wäre), dann würde diese erste TAN später bei der Übertragung mit der zweiten TAN schon längst verfallen sein und das Ganze nicht klappen. Somit muss SFIRM bei Volksbank/Fiduzia die Doppelzeichnung sofort direkt hintereinander am gleichen Arbeitsplatz anfordern und sofort übertragen.

@Nemo: Was hat pushTAN 1.0 und 2.0 damit zu tun? Garnichts, würde ich mal sagen. Denn man kann ja auch chipTAN verwenden.

Das Einzige auf was es ankommt ist, dass der Bankrechner die getrennte Zeitunabhängige Übertragung der ersten und der zweiten TAN anbietet. Und das geht nunmal nur bei FI und bei Fiduzia nicht. FI hat halt diese Doppelzeichnung weiterentwickelt, was Fiduzia nicht getan hat. "Früher" musste Doppelzeichnung - wenn sie überhaupt möglich war - bei allen Banken in einem zusammenhängenden Dialog gemacht werden - was die Sache natürlich nahezu unbenutzbar gemacht hat. Denn es war schon immer schwierig bis unmöglich, zwei Zeichnungsberechtigte gleichzeitig vor einen Rechner zu bekommen um diese Prozedur durchzuführen. Egal ob es sich jetzt um Firmen oder auch Vereine handelt, wo die Beteiligten meistens nicht mal am gleichen Ort sind.

Da liegst Du falsch. Es hat sehr viel mit PushTAN 2.0 (oder korrekter mit dem Decoupled Verfahren) zu tun.

Wenn man an zwei Arbeitsrechnern unabhängig voneinander Unterschriften leisten möchte, gab es bisher zwei Ansätze
1. Der Auftrag wird vor dem Versand an einem Arbeitsplatz unterschrieben und in der gemeinsamen Software geparkt. Anschließend nimmt der nächste Anwender den Auftrag an einem weiteren Arbeitsplatz und versendet den Auftrag. Beim Versand erfolgt dann die zweite Unterschrift. Funktioniert in FinTS nur mit den Signaturverfahren

2. Der Auftrag wird am ersten Arbeitsplatz unterschrieben und an die Bank gesendet. Dort wird der Auftrag geparkt und wartet auf die zweite Unterschrift durch den zweiten Arbeitsplatz. Dazu muss der zweite Arbeitsplatz wissen, welcher Auftrag denn bei der Bank liegt. Dazu werden Details vom Auftrag abgerufen, und diese dann am zweiten Arbeitsplatz unterschrieben. Das funktioniert über mehrere Softwareinstallationen hinweg. Würde auch mit allen Sicherheitsmedien grundsätzlich funktionieren. Am "würde" kann man schon erkennen, gibt es in FinTS nicht, bzw. gibt es erst in FinTS 4.X, welches aber bei keiner Bank an der Kundenschnittstelle aktiv ist.

Die Variante 1 funktioniert mit den bisherigen TAN Verfahren nicht, da die Bank der Anwendung mitteilt, wie die TAN zu erzeugen ist. Dazu muss ein Dialog mit der Bank statt finden. Da es Version 2 nicht gibt, bleibt nur die Möglichkeit, dass die TANs innerhalb eines Sendedialoges erzeugt und eingegeben werden. Das könnte man mit einem Server auf dem der FinTS Dialog läuft und zwei Arbeitsplätzen technisch vielleicht hinbekommen, ist aber mit so vielen Haken und Ösen versehen, dass das keine Anwendung macht.

Warum funktioniert das mit PushTAN 2.0?
Push TAN 2.0 ist kein TAN Verfahren. Es bedient sich nur der FinTS Abläufe eines TAN Verfahrens.
Der Ablauf ist daher anders und hat ein wenig von Variante 1 und Variante 2 und eigenen Abläufen.
Der wichtigste Unterschied ist, die Freigabe erfolgt weitestgehend unabhängig von der Software, mit der der Auftrag versendet wurde. Der Auftrag wird ein gereicht, bei der Bank geparkt. Die weiß, dass der Auftrag im Decoupled Verfahren frei gegeben werden soll und Pusht eine Freigabeanforderung an die jeweiligen Apps. Dort erfolgt die Kontrolle und Nachfrage, ob der Auftrag frei gegeben werden soll. Wird das bestätigt, sendet die App, die Freigabe direkt zurück an die Bank. Die Software ist da komplett außen vor. Sie wartet nur darauf, dass die Bank ihr sagt, dass der Auftrag freigegeben ist und der Dialog weiter geführt werden kann. Dazu fragt die Software in einer Schleife ständig bei der Frank nach, wie der Status der Freigabe ist.
Um das zielgerichteter zu können, gibt es die Möglichkeit, dass der Anwender der Anwendung bestätigt, dass die Freigabe erfolgt ist (ein entsprechendes Knöpfchen drückt). Genau das geht hier bei den Sparkassen auch an mehreren Arbeitsplätzen. Der Unterschied ist halt, es gibt keine TAN Eingabe mehr in der Anwendung.
Daher funktioniert das nur mit "PushTAN 2.0".

den letzten Satz könnte man jetzt aufgrund der Fragestellung falsch verstehen, weil es ja offensichtlich mit einem Chip-basierten TAN-Verfahren bei den Sparkassen funktioniert.
Ich vermute, es liegt daran, dass die Sparkassen mit FinTS teilauthorisierte Aufträge auf ihren Servern liegen lassen können, die Fiducia & GAD IT AG = atruvia-Banken nicht, hier kann man meines Wissens nur komplett unterschriebene Aufträge verarbeiten.
Die Lösung wäre HBCI mit Signatur (Signaturdatei/Chipkarte) zu verwenden oder eben auf EBICS zu wechseln.
Gruß
Raimund

@Holger Fischer: Ich bin da noch etwas skeptisch, muss ich sagen:

Der Originalposter schreibt ausdrücklich von TAN-Eingabe und nicht von push-Freigabe.
Ist die Eingabe einer pushTAN bzw. Direktfreigabe nicht zeitbeschränkt? Kann ich eine Freigabeaufforderung (für den zweiten Nutzer) in der App erst Stunden später durchführen? Sollte das da dann nicht längst verfallen sein?

@Raimund Sichmann: Genau so würde ich es auch sehen und hatte es ja auch so geschrieben.

Ich weiß schon, was der Poster geschrieben hat. Aber was jemand glaubt was er gemacht hat und was er wirklich gemacht, hat sind erfahrungsgemäß schon mal unterschiedlich.

Mit einem normalen TAN Verfahren gibt es im FinTS Ablauf keine Möglichkeit einer zeitversetzten Unterschrift. Liegt einfach daran, dass die Bank im Dialog der Anwendung mitteilt wie die TAN zu erzeugen ist.
Wollte man das zeitversetzt lösen, muss es -wie in EBICS- eine Möglichkeit geben, die Bank dazu aufzufordern mir mitzuteilen, wie ich die TAN aus einem anderen geführten FinTS Dialog unterschreiben soll.
Oder ich muss mir in der Anwendung diverse Dinge merken und der Bank in einem neuen Dialog sagen, dass die TAN jetzt für diesen Auftrag aus einem anderen Dialog stammt.

In beiden Fällen müsste die Bank den Auftrag dialogübergreifend parken können und es Mechanismen geben, die es mir erlauben auf diesen Auftrag zuzugreifen. Mir fehlt aktuell die Phantasie, wie das im Rahmen der vorhandenen Spec unter FinTS 3.0 funktionieren soll/könnte.
Daher ist es eine Abwägung der Wahrscheinlichkeiten
Die größte Wahrscheinlichkeit hat - Falsche Wahrnehmung und es läuft im Rahmen des Decoupled Ansatz wie geschrieben
Danach, die SPKs haben einen proprietären Prozess und /oder GV im Einsatz der das erlaubt
Und ganz unwahrscheinlich Es geht mit den vorhandenen GVs und Prozessen

Also erstmal vielen Dank für die vielen Antworten!

Die haben mir geholfen die richtigen Fragen bei der Bank zu stellen und jetzt eine eindeutige Antwort zu erhalten.

Nach Aussage der Volksbank (der Bank, wo das Verfahren nicht ging) ist es wohl wie folgt:

Der Grund, wieso der Abfragedialog in S-Firm (TAN des zweiten Benutzers jetzt oder später) einfach übersprungen wird ist, dass für uns wohl das HBCI/FinTS (PIN-TAN Verfahren) maßgeblich ist. Die Volksbank bzw. deren Rechenzentrum Fiducia unterstützt aber lt. Aussage der Bank keine zeitversetzte TAN Eingabe.

Man vermutet, dass S-Firm die Option (TAN-Eingabe des 2. Benutzers jetzt oder später) deshalb gar nicht anzeigt, weil das Rechenzentrum das nicht anbietet, sondern die Bankserver direkt an S-Firm kommunizieren, dass die TAN-Eingabe sofort erfolgen muss oder der Auftrag abgelehnt wird.

Die Sparkasse bzw. deren Rechenzentrum unterstützt das hingegen schon.

Was ich im Eingangspost nicht erwähnt habe, dass es einen dritten Benutzer gab, mit dem die anderen zwei Benutzer den Abfragedialog (TAN jetzt oder später) erhalten haben. Das hat natürlich alle auf Irrwege getrieben, weil das ja eigentlich nicht sein kann, wenn das Rechenzentrum das nicht unterstützt.

Der Grund, so vermutet man, ist wohl, dass dieser dritte Benutzer im Gegensatz zu den anderen zwei Benutzern eine (E) Vollmacht statt (A) Vollmacht hat.

Also unabhäng davon, dass in S-Firm zwei Benutzer (Ausführend & Beteiligt) für Auftrage bei der Volksbank gewählt wurden und S-Firm auch hier eine zweite Authentisierung abgefragt hat, war die Authentisierung der zweitem Person ohnehin nicht notwendig.

Was für Alternativen sollen lt. Volksbank funktionieren, damit eine zeitversetzte Unterschrift möglich ist:

a) HBCI-Chipkarte (also mit Chipkartenleser und nicht mit PIN/TAN)
b) HBCI-Benutzerkennung (mit Sicherheitsdatei und z.B. Stick)
c) EBICS

Bei HBCI/FinTS geht es wohl bei der Volksbank nur so, dass sich die Mitarbeiter auf den Schoß von dem jeweils anderen Mitarbeiter setzen und an der
gleichen Arbeitsstation authentisieren.

@TS1
Deswegen wird bei den Volksbanken das PINTAN-Verfahren mit zwei Unterschriften eigentlich auch nicht für Nutzung mit einem ZV-Programm empfohlen. Technisch möglich aber im täglichen Ablauf nicht sinnvoll. Auf der Homepage der Volksbanken funktioniert es hingegen mit zwei zeitversetzten Unterschriften.
Wenn man im Volksbankenbereich mit zwei zeitversetzten Unterschriften über ZV-Programm arbeiten möchte, ist das einzige sinnvolle Verfahren EBICS. Da kann der zweitfreigebende Nutzer auch über eine App die Auftragsfreigabe machen und erhält bei Eingehen eines Auftrages, welchen er zeichnen kann, eine Push-Benachrichtigung diesbezüglich.

Das kann ich mir nicht verkneifen jetzt: Es war/ist also genau so, wie ich es geschrieben hatte.

Wenn die zeitversetzte Eingabe über das WebBanking funktioniert (woran ich keinen Zweifel habe), dann gibt es noch eine Möglichkeit d). Die wäre dann sicher auch preiswerter als EBICS. Und zur Möglichkeit b): Die sollte man wohl eher nicht mehr ins Auge fassen. Hintergrund ist, dass schon sehr viele VR-Banken die Sicherheitsdatei gekündigt haben und nicht mehr anbieten. Ich gehe davon aus, dass die Methode über kurz oder lang ganz eingestellt wird.

Nun zur Möglichkeit d): Man kann die Aufträge wie bisher ganz normal in SFIRM verarbeiten, dann aber nicht direkt per HBCI senden sondern als SEPA-XML-Datei exportieren. Damit ist der Vorgang für SFIRM dann erledigt. Die XML-Datei lädt dann der erste Zeichnungsberechtigte im WebBanking hoch und gibt sie mit einer TAN frei. Damit steht sie dann teilfreigegeben für den zweiten Zeichnungsberechtigten bereit. Dieser loggt sich orts- und zeitunabhängig in sein WebBanking ein und gibt den Auftrag mit seiner zweiten TAN frei - fertig.

Bitte entschuldigt, dass die Antwort bzw. Lösung so spät kommt. Ich wollte das aber fairerweise noch
hier notieren, damit ein anderer Hilfesuchender die Lösung findet:

Hinweis: Wir sind zwischenzeitlich vom PIN/TAN Verfahren auf HBCI-Chipkarte gewechselt in der Hoffnung, dass das Problem dadurch verschwindet. Das alleine war leider nicht die Lösung, da das Verhalten von S-Firm da identisch war. Ich erwähne es dennoch.

b]Lösung:[/b]

Jetzt mag es ja sein, dass das Fiducia Rechenzentrum keine zeitversetzte TAN-Eingabe unterstützt. Ist ja alles schön und gut.

Das bedeutet, so wie ich es vereinfacht verstanden habe, dass das Fiducia Rechenzentrum nicht unterstützt, dass der "Ausführende" (1. User) seine Legitimation (mit TAN) auf dem Server "zwischenspeichert", bis der "Beteiligte" (2. User) sich auch legitimiert hat.

Aber niemand hat gesagt, dass das technisch so sein muss.

Was wir ja lediglich wollten ist, dass zwei User von zwei Arbeitsstationen aus und zeitlich unabhängig, Überweisungsaufträge im 4-Augen-Prinzip verschicken können.

Ob dazu die Legitimation (TAN, Unterschrift, whatever) des Ausführenden im Hintergrund auf irgendeinem Bankserver technisch "zwischengespeichert" wird oder nicht, ist doch uns als Kunden völlig egal.

Und da lag auch die Lösung. Einfach eben nicht auf dem Server zwischenspeichern.

Warum uns von der Bank niemand diesen einfachen weg erklären konnte, verstehen wir bis heute nicht.

Wir haben das über den Punkt "Poolauftrag" gelöst.

1. Ausführender gibt Auftrag an Arbeitsstation 1 aus
2. Im Reiter "Elektronische Unterschrift" wählt der Ausführende den eigenen User und klickt auf "Unterschrift leisten"
3. Legitmation durchführen (bei uns mit HBCI-Chipkarte)
4. Im Reiter "Digitale Unterschrift" ist danach ein "x" neben dem Namen des Ausführenden zu sehen
5. Statt "wie gewohnt" auf ausführen zu klicken, klickt man jetzt auf "Pool"
6. Der Beteiligte an Arbeitsstation 2 sieht jetzt auf dem Startbildschirm "Aufträge im Pool: bitte prüfen"
7. Wird das angeklickt, kann man mit Doppelklick den Poolauftrag öffnen
8. Jetzt erst auf "ausführen" klicken.
9. Legitimation durchführen als "Beteiligter" an Arbeitsstation 2
10. Auftrag wird mit zwei Unterschriften vollständig versendet und ausgeführt.

So konnten wir das gewünschte erreichen.

Zwei User können einen Auftrag zeitlich versetzt von zwei Arbeitsstationen aus autorisieren.

Thread kann also jetzt archiviert/geschlossen werden.

das wird daran liegen, dass SFIRM für eine Genobank eine fremde Software ist. Die Lösung hätte vom SFIRM-Support kommen müssen, so exotisch ist ja das genossenschaftliche Rechenzentrum nicht.
Gruß
Raimund

Ähm Nein. Wie vor einem Jahr schon erklärt:
Mit PIN/TAN ist eine zeitversetzte zweite Unterschrift in FinTS 3.0 nicht spezifiziert. Das hat mit dem Rechenzentrum nix zu tun.
Zweitunterschriften zeitversetzt gehen nur lokal und nur mit den Signaturverfahren.

@Holger Fischer
Die Sparkassen haben da im Zuge des Decoupled TAN anscheinend was eingebaut, was eine zeitversetzte Zweitunterschrift nach Einreichung des Auftrages zuläßt. Meines Wissens nach funktioniert das aber nur Tag gleich.