Die SolarisBank ist seit letztem Donnerstag live mit dem Empfang von Echtzeitüberweisungen.
Das Senden von Echtzeitüberweisungen wird bis zum Ende des Jahres noch folgen.
Da das Implementieren von SEPA Inst. passiv - sprich Empfangen, mit Abstand das Einfachste an SEPA Instant ist, werden wir sicherlich nicht lange darauf warten müssen, bis Tomorrow dieses Feature aktiviert hat, … oder?
Da dieser Punkt im Trello nicht abgebildet ist, würde ich mal den @Marvin anfunken, ob es dazu eine Info gibt.
Moin! Es ist in jedem Fall geplant, das ganze zu implementieren. Wann genau im Quartal das passieren wird, lässt sich aber nicht genau sagen, da das ganze mit einigen organisatorischen Dingen verbunden ist, in die auch Solaris mit eingebunden werden muss.
Ich bin aber guter Dinge, dass es nicht allzu lange dauern wird 
Anscheined gibt es jetzt deshalb Überweisungsprobleme an Konten, welche bei der SolarisBank geführt sind. Da jeder der entsprechenden Partner der SolarisBank dieses Feature noch einzeln nach Absprache bzw. Anpassung mit der SolarisBank aktivieren muss, kommt es
aktuell zu Fehlüberweisungen an die SolarisBank, wenn die sendende Bank die Überweisung by default bzw. automatisch in Echtzeit ausführt - z.B. Revolut, Bunq
oder NL-Banken etc. Alle Banken sehen die Konten bei SolarisBank als erreichbar via SEPA Inst., jedoch die Solaris Bank schreibt den Betrag nicht gut bzw. blockiert den Empfang, weil die entsprechenden Partner wie Tomorrow und co. es noch nicht aktiviert haben. Selbst die Sparkassen oder auch Volksbanken bieten es an, die Überweisung an ein SolarisBank-Konto via SEPA Inst. auszuführen, jedoch kommt diese nach der Ausführung aus dem oben genannten Grund direkt zurück.
Fazit, es ist ein weiteres Armutszeugnis von der SolarisBank…Es wundern sich bestimmt derzeit einige Menschen, warum eine Überweisung an ein SolarisBank-Konto fehlschlägt. Man hätte zumindest das Empfangen für alle Konten gleichzeitig aktvieren sollen, um eben dieses Problem zu vermeiden oder SEPA Inst. erst aktivieren, wenn alle Partner es software-mäßig implementiert haben.
Das ist ne wichtige Info - woher hast du die?
Ich kann das Problem nachvollziehen und habe mich deswegen an den Support gewandt. In der Zwischenzeit: Für Revolut gibt es einen Workaround. Terminüberweisungen, auch mit dem Termin „heute“, scheinen nicht instant gesendet zu werden. Das jedenfalls legt die Darstellung in der App nahe. Meine Test-Überweisung scheint auf dem Weg zu sein. Ich melde mich mit dem Ergebnis.
Es ist mir selbst gestern aufgefallen, als ich meine TF-Bank Kreditkartenrechnung an ein SolarisBank-Konto (die TF-Bank arbeitet neulich mit der SolarisBank für die Zahlungsabwicklung) in Echtzeit überwiesen habe. Meine Volksbank hat es mir angeboten, die Überweisung in Echtzeit auszuführen, da ja das Konto theoretisch via SEPA Inst. erreichbar ist. Das Geld kam nach der Überweisungsausführung direkt zurück mit dem Vermerk, dass der Empfänger diese Überweisungsart nicht unterstützt. Ich habe dann von Bunq und Revolut versucht, einen Betrag an mein Tomorrow und Vivid Konto zu überweisen. Ich habe schon geahnt, dass dieser Fehler genauso auftreten würde, da Bunq und Revolut nur noch ausschließlich in SEPA Inst. standardmäßig überweisen, sofern der Empfänger instant erreichbar ist. Zwei Freunde konnten dieses Phänomen ebenfalls bestätigen. Ich hoffe, dass die SolarisBank da sofort eine Fehlerbehebung vornimmt bzw. SEPA Inst. umgehend ausschaltet, da es wirklich inakzeptabel ist, dass eine Überweisung aus dem Grund an ein SolarisBank-Konto nicht ausgeführt werden kann…
It takes two to tango, sage ich mal. Teil von SCT Inst ist ja die Rückmeldung des Empfängers, dass das Geld dort nun verfügbar ist. Dass ein Konto vorübergehend mal nicht via SCT Inst erreichbar ist, ist eigentlich eingeplant – bei Wartungsarbeiten zum Beispiel. Diese Rückmeldung erfolgt, und führt zu den Fehlermeldungen, die ja einen korrekten Grund angeben.
In diesem Fall ist eigentlich im Interesse des Senders, auf eine reguläre SEPA-Überweisung ausweichen zu können. Diese Fallback-Option hat nun Revolut zum Beispiel wohl nicht implementiert.
Die Überweisung war erfolgreich.
Es liegt definitiv nicht an Revolut. Wenn es so wäre, hätten es gleich zumindest drei Institute falsch implementiert, das ist nahezu unmöglich. Die Volksbanken, Bunq (EU Vorreiter, damals in 2017 bei SEPA Inst.), oder auch Revolut haben da sicherlich viel mehr Erfahrung als eine SolarisBank, die jetzt erst damit begonnen hat. Es liegt definitiv an der Solaris Bank, welche den Betrag nicht gutschreibt, weil ein bestimmtes Konto im Endeffekt dafür nicht freigeschaltet wurde - siehe die gesonderte Behandlung mit jedem Partner der SolarisBank bezüglich der Freischaltung von SEPA Inst. Die Solaris Bank täuscht quasi damit vor, eine SEPA Inst. empfangen zu können, um sie dann sofort abzulehnen, da das Brand noch keine Freischaltung / Implementierung bekommen hat. Die Bank ist jedoch mit ihrem Empfangskanal technisch online, sodass jede Bank welche standardmäßig, automatisiert in SEPA Inst. raussendet auch keinen Rückfall auf SEPA Standard vornimmt, da sie die Solaris Bank doch bei der Prüfung der Erreichbarkeit als Instant-fähig wahrgenommen hat und somit keinen Grund zum Fallback auf eine normale SEPA-Überweisung sieht.
Damit es so ist, müsste die Solaris Bank die Erreichbarkeit ausschalten, damit eben Bunq, Revolut und andere Bankinstitute die Solaris Bank als nicht mehr Instant-fähig bei der Prüfung der Erreichbarkeit ansehen.
Ist den jetzt absehbar .
Wann Tomorrow Plant , die Echtzeitüberweisung einzuführen.
Oder steht das noch in weiter Ferne.
Weil ich würde es auf jeden fall begrüßen , auch wenn man dafür eine kleine Gebühr Zahlen müsste.
Mittlerweile bieten ja so gut wie (fast) alle Banken die Echtzeitüberweisung an.
Die generelle Erreichbarkeit ist erst einmal nichts weiter als ein Telefonbuch: Eine Bank schaut nach, ob ein potenzieller Empfänger erreichbar ist. Es ist kein Live-Status über die Empfangsbereitschaft eines konkreten Empfängers.
Im Verlauf der Echtzeitüberweisung gibt es einen Rückkanal. Dieser meldet dem Sender, dass die Überweisung erfolgreich war – oder eben nicht – und dass das Geld nun für den Empfänger verfügbar ist. Das ist so vorgesehen. Es kann eine Reihe von technischen Gründen haben, warum der Transfer nicht klappt. Ich kann mich selbst daran erinnern, dass die Comdirect nach Einführung von SCT Inst mehrfach nicht per SCT Inst erreichbar war. Ich hatte damals selbst dort noch ein Depot, und habe das häufiger genutzt. Ich nehme hier Solaris auch nicht aus der Verantwortung, das sauber zu implementieren oder eine gute Lösung zu finden, die in erster Linie im Interesse der Kund:innen ist.
Die Frage ist aber durchaus: Wie sieht die User Experience denn auf Seiten der Senderbank aus, wenn Echtzeitüberweisung nicht klappt. VR und Sparkassen (u.a.) haben hier eine einfache Lösungsoption: Fallback auf normale SEPA-Überweisung. Bei Revolut habe ich mir die Sache selbst angesehen: Hier ist es eben so, dass man nicht manuell wählen kann. Das verhindert effektiv den Transfer. Ein einfacher Hinweis, sinngemäß „Echtzeitüberweisung schlug fehl. Normal senden?“ wäre eine mögliche Lösung. Was dann geklappt hat ist die Terminüberweisung. Über diesen Umweg zwingt man Revolut quasi, den Transfer als reguläre SEPA-Überweisung auszuführen.
Ich denke, in Bezug auf die User Experience bei den sendenden Banken und einer fehlgeschlagenen SEPA Inst. Überweisung wird es keinen direkten Hinweis darauf geben, dass die Überweisung als Standard ausgeführt werden kann/muss, nachdem die Bank eben erfuhr, dass sie in Echtzeit ankommen würde.
Da die Information über eine fehlgeschlagene SEPA Inst. Überweisung erst ein paar Sekunden später kommt, muss der User mit Umwegen (siehe Revolut) oder manuell durch Neuanlage (siehe Volksbank oder Sparkasse) die entsprechende Überweisung als eine normale SEPA Überweisung ausführen. Die sendenden Banken haben doch nicht voraussehen können, dass es mal eine Bank im SEPA-Raum geben wird, welche SEPA Inst. technisch empfangen kann, aber aufgrund von unterschiedlicher Handhabung in Folge der internen Richtlinien (Sprichwort Partner-Aktivierung) die Echtzeitüberweisung letztendlich doch nicht gutschreiben möchte.
Deshalb sind heute z.B. alle Kunden von Bunq und anderen niederländischen Banken, welche ausschließlich auch Daueraufträge in Echtzeit senden, nicht in der Lage einen Betrag an die SolarisBank zu überweisen. Die SolarisBank hat sich einfach keine Gedanken darüber gemacht, dass solche Differenzierung bei deren Partnern wegen der Aktivierung zu Problemen führen kann, wenn die sendende Bank ausschließlich in Echtzeit überweist, wenn sie die technische Fähigkeit des Empfängers wahrnimmt.
Die SolarisBank hat sich quasi für einen Alleingang in der Branche entschieden, anscheinend ohne genaue Prüfung im Vorfeld. Ich bin mal gespannt, was Tomorrow diesbezüglich von der Solaris Bank erfahren wird und welche Lösungen nun herangezogen werden. Ich habe heute ein paar ähnliche Tweets gelesen, gerichtet von Usern an Revolut und Bunq, aber auch einen direkt an die SolarisBank, sodass zunehmend mehr Menschen auf dieses Problem stoßen.
Der Prozess, wie SCT Inst abläuft, ist ja eigentlich geregelt. Es gibt ein System, dass Erfolg oder Misserfolg der Transaktion meldet.
Mir scheint es, du ignorierst alle anderen Fälle, bei denen SCT Inst scheitert, weil der Empfänger nicht erreichbar ist. Die gibt es. Zum Beispiel bei Wartungen.
Im „Scheme Rulebook” des European Payments Council (EPC) zum Beispiel steht:
The Scheme specifies a set of positive and negative messages in the inter-PSP area to confirm to the Originator PSP Immediately if an SCT Inst Transaction has been successfully processed or has been rejected by one of the inter-PSP parties involved.
Latest at 10 seconds after the Originator PSP has put the Time Stamp in accordance with section 4.2.1 to the SCT Inst Transaction and Instantly sent the SCT Inst Transaction to the Beneficiary PSP, the Originator PSP must have received either the message that the Funds have been Made Available to the Beneficiary by the Beneficiary PSP (positive confirmation message), or the message that the SCT Inst Transaction has been rejected (negative confirmation message with the appropriate reason code).
Was die Bank des Senders jetzt mit einer Ablehnung macht, das ist dann eben in der Hand der Absenderbank. Es ist jedenfalls eine Tatsache, dass die Ablehnung einer Transaktion im Design des Prozesses vorgesehen ist und kein außergewöhnliches Ereignis darstellt.
Ich denke auch, dass Solaris das nicht ganz durchdacht hat. Revolut und Bunq aber eben auch nicht. Das eine schließt das andere nicht aus.
Ja, du hast damit natürlich Recht, dass eine Ablehnung im Prozess vorgesehen ist, jedoch wird sie dann anscheinend nicht so behandelt, wie z.B. direkt eine fehlende Erreichbarkeit am Anfang des Überweisungsprozesses.
Wenn z.B. eine Echtzeitsammelüberweisung via EBICS oder HBCI vorgenommen wird, und im Sammler 1-2 Empfänger nicht SEPA instant-fähig sind, wird dann direkt eine Standardüberweisung statt SEPA instant ausgeführt. Basierend auf den Vorkommnissen könnte mal die These aufstellen, dass bei einer fehlenden Gutschrift in Echtzeit trotz zuvor gemeldeter Erreichbarkeit mit dem Überweisungsauftrag bei der sendenden Bank nichts mehr zwecks Ausführung passiert. Die Bank schreibt ja den Betrag wieder gut und der Zahlungsauftrag muss neu erfasst werden und kann - sofern die Bank nicht ausschließlich immer in Echtzeit versendet - als normaler SEPA Credit Transfer rausgeschickt werden.
Gibt es inzwischen eine Rückmeldung von dem Support der SolarisBank zu dem Sachverhalt?
Das gibt es nicht. Was es gibt ist ein allgemeines Verzeichnis der Banken, welche an SCT Inst technisch angeschlossen sind. Darin ist Solaris aufgeführt. Auf dieser Basis bietet dann z.B. die Sparkasse die Option Echtzeit an.
Zu diesem Zeitpunkt ist im Prozess aber eben keine Live-Überprüfung der tatsächlichen momentanen Erreichbarkeit vorgesehen. Es ist wie ein Telefonbuch. Erst wenn du anrufst, weißt du, ob jemand am anderen Ende abhebt. Wenn besetzt ist oder keiner rangeht, kommt das Telefonat nicht zustande. So ist der Prozess auch für SCT Inst gestaltet.
Deswegen gehe ich davon aus, dass alle Beteiligten den eigenen Prozess nach den Regeln des Schemes umgesetzt haben. Aber weil sowohl Solaris wie auch Revolut/Bunq diesen Fall nicht bedacht haben, holpert es. Jeder in der Kette hier hat es in der Hand, im Sinn der eigenen Kunden das Problem zu beheben.
Revolut, Bunq und co. da eine Mitschuld geben zu wollen halte ich für falsch. Solaris hat die Situation verursacht.
Ich sehe es auch so. Die Solaris Bank hätte einfach so lange wie noch notwendig warten können, bis sie mit der Erreichbarkeit online geht, davon abhängig, ob alle Partner den Incoming SEPA Inst. Flow implementiert haben. Dann gäbe es dieses Problem mit Fehlüberweisungen nicht. Es ist recht eindeutig, woran es liegt und warum die Gutschrift bei einem SolarisBank geführten Konto nicht erfolgt, obwohl die technische Unterstützung für den Empfang einer SEPA Inst. Überweisung gegeben ist.
ich bin da bei Frnk - verstehe aber auch vollkommen, dass Solaris das nicht gut angegangen ist.
Meine ach so un-neo Sparkasse bietet aktuell keine Echtzeit-ÜW an Solaris an, ist ausgegraut. Die wissen wohl warum … aber wenn mal ein Echtzeit nicht durchgeht (ich hatte das mal als bunq Probleme hatte), wird das gemeldet und dann als normale Sepa-Überweisung ausgeführt. So sollte das sein, nicht anders.
Diese Sicht finde ich wiederum verkürzt. Natürlich ist Solaris da nicht von frei, aber wenn erfolgreiche Sofortüberweisungen von beiden Parteien vollständig unterstützt werden müssen, in all ihren Facetten, dann muss man die Fehlersuche eben auch auf beiden Seiten machen. Ist wie im Straßenverkehr: du kannst noch so gut fahren, wenn jemand anderes einen Fehler macht, kracht es trotzdem. In diesem Fall gibt es mehr als ein Problem bei mehr als einer Partei, und beide Parteien müssen nachbessern. Verstehe auch nicht so ganz, was hier gewonnen wird, wenn nur Solaris Schuld wäre.