Transaction Screening API oder Sanctions & PEP API: Was passt zu Ihrem Zahlungsworkflow?

Checklynx bietet zwei API-Modelle, die Prüfungen in einem Zahlungsworkflow unterstützen können, die Verantwortung jedoch unterschiedlich zuordnen.

Nutzen Sie POST /transactions, wenn die Zahlung und ihre Parteien zu einem dauerhaften Transaction-Screening-Lauf in Checklynx werden sollen. Jede Anfrage erzeugt eine neue Lauf-ID, hält die übermittelten Parteien in einem gemeinsamen Transaktionskontext zusammen, ermöglicht den späteren Abruf und kann handlungsrelevante Ergebnisse mit einem Checklynx-Fall verknüpfen.

Nutzen Sie POST /check/sanctions_pep, wenn Ihre Anwendung das führende System für Transaktion und Workflow bleiben soll. Der Endpunkt prüft ein Ziel direkt gegen Sanktions-, PEP- und Fahndungslistendaten. Ihre Anwendung bleibt dafür verantwortlich, den maßgeblichen Datensatz zu Zahlungskontext, Parteienbeziehungen, Korrelation, Nachweisen und nachgelagertem Prüfworkflow selbst aufzubewahren.

Dies ist nicht einfach eine Wahl zwischen „mehr“ und „weniger“ Prüfung. Es ist eine Entscheidung darüber, welches System die Ausführung des Transaction Screenings und das Nachweismodell verantwortet.

Die Entscheidung auf einen Blick

Die Transaction Screening API hält mehrere übermittelte Parteien innerhalb einer Checklynx-Ausführung zusammen:

Zahlungsereignis des Kunden → POST /transactions → Checklynx-Lauf-ID → Parteienergebnisse und Laufnachweise → optionaler Fall → Kundenentscheidung

Die direkte Sanctions & PEP API belässt diese Struktur in der Kundenplattform:

Zahlungsereignis des Kunden → Partei auswählen → POST /check/sanctions_pep → Antwort unter Kundentransaktion und Partei speichern → nach Bedarf wiederholen → Prüfung beim Kunden → Kundenentscheidung

Beide Modelle können einen Zahlungsworkflow speisen. Entscheidend ist, ob Checklynx einen nativen Transaktionslauf vorhalten oder als direkte Prüfschicht innerhalb einer Architektur dienen soll, die bereits den vollständigen Transaktions- und Prüfdatensatz verantwortet.

Wenn die zugrunde liegende Frage stattdessen lautet, wie sich Transaction Screening vom verhaltensbasierten Monitoring unterscheidet, lesen Sie Transaction Screening im Vergleich zu Transaction Monitoring. Dieser Leitfaden behandelt diese Abgrenzung nicht erneut.

Was POST /transactions erstellt

POST /transactions ist transaktionsorientiert. Die Anfrage enthält ein transaction-Objekt und ein screening-Objekt. Für die Transaktion sind eine vom Kunden bereitgestellte transaction_reference_id und parties erforderlich; für das Screening-Objekt ist eine screening_profile_id erforderlich.

Die Transaktion kann außerdem Typ, Ausführungszeitpunkt, Betrag und Währung enthalten. Zu den derzeit dokumentierten Transaktionstypen gehören Bankzahlung, Kartenzahlung, Geldüberweisung, Bareinzahlung, Barabhebung, interne Übertragung und Sonstiges. Diese Felder ergänzen die Ausführung um Zahlungskontext; sie bestimmen nicht die rechtliche Behandlung der Zahlung.

Die Antwort enthält eine von Checklynx generierte id, eine Transaktionszusammenfassung, den Ausführungs-status, hit_status, hit_count, screening_summary, den Erstellungszeitpunkt, Ergebnisse je Partei und eine case_id, die null sein kann. Der aktuelle Vertrag definiert den Laufstatus als completed oder failed und den Trefferstatus als hit oder clear. Ein Trefferstatus spiegelt handlungsrelevante, nicht unterdrückte Ergebnisse im konfigurierten Prüfworkflow wider; er ist keine abschließende rechtliche Beurteilung.

Die genauen Schemas können sich ändern. Implementierungen sollten daher den aktuellen Checklynx-Entwicklerleitfaden und die OpenAPI-Definition als maßgeblichen Vertrag verwenden.

Mehrere Parteien bleiben einem Transaktionslauf zugeordnet

Die Transaktionsanfrage unterstützt eine bis 100 Parteien. Derzeit dokumentierte Rollen sind:

debtor, creditor, customer, counterparty, ultimate_debtor, ultimate_creditor, debtor_agent, creditor_agent, intermediary_agent und merchant.

Jede Partei benötigt eine Rolle und mindestens eine verwertbare Prüfeingabe: einen Namen, ein Identitätsdokument oder ein unterstütztes Zahlungsinstrument. Eine optionale external_customer_id kann die Partei über die stabile Kennung des Kunden einem bestehenden Checklynx-Kunden zuordnen. Kann sie nicht aufgelöst werden, prüft Checklynx dennoch die übermittelten Parteiendaten und lässt die Partei für diesen Lauf unverknüpft.

Das native Parteienmodell ist nützlich, wenn Auftraggeber, Begünstigter, Intermediär, Händler oder andere richtlinienrelevante Rollen mit derselben Ausführung verbunden bleiben müssen. Die Rollenliste beschreibt, was die API unterstützt – nicht, welche Parteien ein Unternehmen rechtlich prüfen muss. Der Umfang muss den anwendbaren Anforderungen und der Kundenrichtlinie folgen.

Das Prüfprofil gehört zum Lauf

Die Anfrage erfordert screening.screening_profile_id. Dies identifiziert das Checklynx-AML-Prüfprofil, das auf den Transaktionslauf angewendet wird. Damit erhält der Transaktionsworkflow einen konfigurierten Prüfungskontext, ohne dass jede Transaktionsanfrage sämtliche Prüfkontrollen erneut abbilden muss.

Das geprüfte Anfragemodell für POST /check/sanctions_pep enthält keine screening_profile_id. Stattdessen bietet es direkte Steuerelemente wie Unschärfe, Ausschlüsse und Filter. Das ist ein praktischer Unterschied: Das eine Modell ruft ein konfiguriertes Profil für einen Transaktionslauf auf, das andere übermittelt eine direkte Zielprüfung mit Prüfparametern auf Anfrageebene.

Bankkonten und Wallet-Adressen werden unterschiedlich behandelt

Das aktuelle Modell für Transaktionsparteien unterstützt die Zahlungsinstrumente bank_account und wallet_address.

Für ein dokumentiertes bank_account-Instrument benötigt die Anfrage Kontonummer und BIC. Checklynx verwendet den BIC für die Sanktionsidentitätsprüfung. Die Kontonummer wird als unterstützender Laufnachweis aufbewahrt, derzeit jedoch weder geparst noch per Prüfsumme validiert oder selbst geprüft. Die zutreffende Beschreibung lautet daher „BIC geprüft, Kontonummer als Nachweis gespeichert“ – nicht pauschal „IBAN-Prüfung“.

Bei einem wallet_address-Instrument wird die Wallet-Adresse für die Sanktionsidentitätsprüfung verwendet. Die Angabe eines Netzwerks ist optional.

Beide unterstützten Instrumenttypen können eine optionale kundenseitige external_instrument_id enthalten. Sie kann mit dem Lauf zurückgegeben werden, ist laut aktuellem Vertrag jedoch nicht in Falltrefferdatensätzen oder Webhook-Payloads enthalten. Sie sollte daher nicht der einzige systemübergreifende Korrelationsschlüssel für Fälle in der Integration sein.

Prüfungen von Zahlungsinstrumenten setzen voraus, dass die Sanktionsidentitätsprüfung im ausgewählten Prüfprofil aktiviert ist.

Fachliche IDs, Lauf-IDs und Fall-IDs lösen unterschiedliche Aufgaben

Der Transaktionsworkflow verwendet drei Kennungen, die nicht miteinander verwechselt werden sollten:

Jeder Aufruf von POST /transactions erstellt einen neuen Prüflauf, auch wenn dieselbe transaction_reference_id erneut übermittelt wird. Dieses Verhalten unterstützt eine berechtigte erneute Prüfung: Mehrere Ausführungen können zu derselben fachlichen Zahlung gehören, wobei jede ihr eigenes Ergebnis und ihren eigenen Zeitstempel behält. Es bedeutet zugleich, dass der Kunde versehentliche doppelte Übermittlungen verhindern oder abgleichen muss.

Speichern Sie die zurückgegebene Lauf-id zusammen mit dem Transaktionsdatensatz des Kunden. GET /transactions/{id} ruft diese konkrete Ausführung ab. GET /transactions/references/{transaction_reference_id} gibt ein Aggregat für Läufe mit derselben fachlichen Referenz zurück, und GET /transactions listet Transaktionsreferenz-Aggregate mit dokumentierten Filter- und Paginierungsoptionen auf. Eine Referenzabfrage sollte nicht so behandelt werden, als identifiziere sie einen einzelnen eindeutigen Lauf.

Diese Unterscheidung ist bei unklaren Fehlern wichtig. Wenn ein Aufrufer nicht weiß, ob eine Anfrage erfolgreich war, kann eine unbedachte Wiederholung einen weiteren Lauf erzeugen. Der Kunde benötigt einen anwendungsseitigen Übermittlungsstatus und eine Abgleichsstrategie; der aktuelle öffentliche Vertrag verspricht keine Exactly-once-Verarbeitung.

Was POST /check/sanctions_pep anders macht

Der direkte Endpunkt prüft ein Ziel gegen Sanktions-, PEP- und Fahndungslistendaten. Er erstellt ausdrücklich keinen Kunden- oder Falldatensatz, und sein öffentlicher Antwortvertrag enthält weder ein Transaktionsobjekt noch eine kundenseitige Transaktionsreferenz oder eine persistente Transaction-Run-ID, die der Lauf-id von /transactions entspricht.

Die Anfrage stellt genau eine der folgenden Angaben bereit:

• search_term für eine namensbezogene Prüfung, beispielsweise den Namen einer Person, eines Alias, Unternehmens, Schiffs oder Luftfahrzeugs; oder
• search_identity für eine kennungsbezogene Prüfung, beispielsweise einen Reisepass, eine Steuer-ID, nationale ID, andere Dokumentennummer, IMO-Nummer eines Schiffs, einen Wallet-Wert oder einen vom aktuellen Vertrag unterstützten Bankkontowert.

Die aktuelle OpenAPI-Dokumentation beschreibt die Unschärfewerte "0", "1" und "2", wobei "1" der Standardwert ist. Außerdem dokumentiert sie Filter und Ausschlüsse, unter anderem nach Quelltyp, Gruppentyp, Staatsangehörigkeit, Geburtsjahr und Geschlecht. Die Antwort ist nach results und match_profiles strukturiert.

Dies sollte als direktes Prüfmodell ohne persistiertes Checklynx-Transaktionsobjekt beschrieben werden, nicht als Garantie für buchstäblich keinerlei Backend-Speicherung oder Betriebsprotokollierung. „Zustandslos“ ist eine gängige Marktbezeichnung, der öffentliche Vertrag begründet diese absolute Aussage für Checklynx jedoch nicht.

Mehrere Zahlungsparteien mit dem direkten Endpunkt prüfen

Möchte ein Kunde mehrere Parteien prüfen, ruft er den Endpunkt für jedes relevante Ziel separat auf und bildet die Zahlungsbeziehung in seinem eigenen System nach. Eine zweckmäßige kundenseitige Zuordnung lautet:

Kundentransaktions-ID → Partei und Rolle → Anfrage-Payload und Parameter → Antwort und match_profiles → Zeitstempel → Prüfstatus → Workflow-Ergebnis

Zurückgegebene Ergebnis- oder Trefferkennungen sollten nicht als Transaction-Run-IDs bezeichnet werden. Der Kunde sollte vor dem API-Aufruf einen eigenen Korrelationsdatensatz anlegen und ihn atomar aktualisieren, wenn sich Ergebnisse, Prüfung und Zahlungsstatus ändern.

Dieses Modell kann zu einer etablierten Zahlungsplattform passen, die bereits über ein Fallsystem, Ereignisjournal und Nachweisarchiv verfügt. Die Plattform behält die Kontrolle darüber, welche Parteien wann geprüft werden, wie Antworten zusammengeführt werden und wo die Prüfung stattfindet. Diese Flexibilität überträgt zugleich mehr Verantwortung auf den Kunden: Rollenbeziehungen, Duplikatschutz, Persistenz, Abruf und Untersuchungshistorie werden bei diesem Endpunkt nicht durch einen nativen Checklynx-Transaktionslauf bereitgestellt.

Die aktuelle öffentliche Dokumentation beschreibt weder einen Idempotenzmechanismus für POST /check/sanctions_pep noch einen Abschluss-Webhook für eigenständige Prüfungen oder eine automatische Fallerstellung. Das sind präzise Grenzen der Dokumentation – keine Behauptung, dass nicht dokumentierte interne Funktionen unmöglich wären.

Architekturvergleich

Keines der Modelle entbindet den Kunden davon, seinen fachlichen Transaktionsstatus und die abschließende Entscheidung aufzubewahren. Der Unterschied besteht darin, wie viel von der Prüfausführung, dem Parteienkontext und der Prüfverknüpfung nativ in Checklynx abgebildet wird.

Auswirkungen auf Nachweise und Fallmanagement

Bewahren Sie bei /transactions mindestens die fachliche Kundenreferenz, die Checklynx-Lauf-id, relevante Anfrage- und Korrelationsdaten, den Status im Zahlungssystem und die nachfolgende fachliche Entscheidung auf. Der Checklynx-Lauf hält die übermittelte Transaction-Screening-Ausführung und die Parteienergebnisse zusammen. Sofern konfiguriert und anwendbar, kann case_id handlungsrelevante Ergebnisse mit einem Prüfworkflow verknüpfen.

Bei /check/sanctions_pep benötigt der Kunde für jede direkte Prüfung einen rekonstruierbaren Datensatz: Transaktionskennung, Partei und Rolle, Zeitstempel, übermittelte Prüfeingabe, Anfrageparameter und Filter, Antwort und match_profiles, nachgelagerten Status, Prüfer, Begründung und Ergebnis. Dies ist eine Architekturempfehlung aufgrund der fehlenden nativen Transaktions-/Fallstruktur dieses Endpunkts, keine Behauptung, Checklynx schreibe ein bestimmtes Kundendatenbankschema vor.

Mögliche Treffer müssen bewertet werden. Sie sollten in den anwendbaren Prüf- und Eskalationsprozess des Unternehmens eingehen, statt als automatischer Beweis behandelt zu werden, dass die Partei sanktioniert ist. Hinweise zum Untersuchungsdatensatz finden Sie unter So dokumentieren Sie die Untersuchung eines Sanktionshinweises; Audit Trail und Nachweise und Fallmanagement erläutern den Checklynx-Workflowkontext.

Authentifizierung, Webhooks und Duplikatschutz

Die aktuelle OpenAPI verwendet den Header x-api-key. Bewahren Sie API-Schlüssel in serverseitigen Systemen und nicht im Browser- oder Mobile-Client-Code auf. Maßgeblich für genaue Authentifizierungs- und Payload-Beispiele ist die aktuelle Entwicklerdokumentation, nicht ältere Beispiele auf Marketingseiten, die vom Vertrag abweichen können.

Für anwendbare Transaktionsfall-Ereignisse dokumentiert Checklynx transaction_screening.case.opened. Dabei handelt es sich um ein Ereignis für einen neu eröffneten Fall infolge handlungsrelevanter Transaction-Screening-Treffer – nicht um einen Callback für jede Transaktionsanfrage.

Webhook-Empfänger sollten:

1. die Rohbytes der Anfrage lesen;
2. base64(HMAC-SHA256(signing_secret, raw_request_body)) berechnen;
3. das Ergebnis vor dem Parsen oder erneuten Serialisieren von JSON mit X-Webhook-Signature vergleichen;
4. Anfragen mit abweichender Signatur ablehnen; und
5. erneut zugestellte Ereignisse anhand der dokumentierten event_id deduplizieren.

Webhook-Deduplizierung und die Vermeidung doppelter Transaktionsanfragen sind unterschiedliche Kontrollen:

Beschreiben Sie die Webhook-Zustellung nicht als Exactly-once. Die dokumentierte Anforderung zur Deduplizierung bedeutet, dass Empfänger mit möglichen Wiederholungen rechnen sollten.

Fehler, Wiederholungen und betriebliche Wiederherstellung

Der öffentliche Vertrag dokumentiert 429 als „Too many requests“ und weist Aufrufer an, zu warten und den Versuch mit Backoff zu wiederholen. Er begründet weder ein allgemeingültiges Kontingent noch eine feste Wartezeit, ein Latenzziel oder ein SLA, das dieser Artikel versprechen könnte.

Trennen Sie Fehler nach Prozessstufe. Eine Zeitüberschreitung beim Transport beweist nicht, dass serverseitig kein Lauf erstellt wurde. Eine abgeschlossene API-Antwort beweist nicht, dass eine nachgelagerte Aktualisierung der Zahlung oder Fallzuweisung erfolgreich war. Erfassen Sie Übermittlungsstatus, die Lauf-ID, sofern zurückgegeben, Antwortstatus, nachgelagerte Übergabe und Abgleichergebnis unabhängig voneinander.

Vermeiden Sie, vollständige Namen, Identitätsdokumente, Kontodaten oder Wallet-Adressen in allgemeine Anwendungsprotokolle zu kopieren. Nutzen Sie bevorzugt nur die für den Betrieb erforderlichen Korrelations-IDs, Status- und Diagnosemetadaten; sensible Nachweise sollten ausschließlich in angemessen kontrollierten Systemen aufbewahrt werden.

Welche API passt zu Ihrer Zahlungsarchitektur?

Die Transaction Screening API ist vorzuziehen, wenn:

• mehrere Parteien mit demselben Zahlungskontext verbunden bleiben müssen;
• ein dauerhafter Checklynx-Ausführungsdatensatz nützlich ist;
• Analysten Transaktions- und Parteienkontext in Checklynx benötigen;
• dieselbe fachliche Zahlung mehrfach geprüft werden kann und jeder Lauf einzeln abrufbar bleiben muss;
• der Abruf anhand der Checklynx-Lauf-ID oder der fachlichen Kundenreferenz wichtig ist;
• handlungsrelevante Ergebnisse mit einem Checklynx-Fall verknüpft werden können sollen; oder
• Prüfausführung und Prüfungsnachweise im Checklynx-Workflow enger miteinander verbunden sein sollen.

Die direkte Sanctions & PEP API ist vorzuziehen, wenn:

• die Kundenplattform bewusst das führende Transaktionssystem ist;
• sie bereits ihre eigene Fall-, Workflow- und Nachweisarchitektur verantwortet;
• die Arbeitseinheit eine direkte Prüfung eines einzelnen Ziels ist;
• der Kunde separat orchestrieren möchte, welche Zahlungsparteien geprüft werden;
• er die Beziehungen zwischen Transaktion, Rolle, Anfrage und Antwort sowie die Prüferzuordnung selbst persistieren kann; oder
• Checklynx als Prüfdienst innerhalb einer umfassenderen kundeneigenen Anwendung dienen soll.

Keines der Modelle ist grundsätzlich besser. Richtig ist das Modell, dessen Verantwortungsgrenzen zu den Systemen passen, die Operations, Engineering und Compliance zuverlässig unterstützen können. Weitere Produktinformationen finden Sie unter AML-Integrationsworkflows, im Checklynx-Transaction-Screening-Workflow und zur Echtzeit-API für Sanktions- und PEP-Prüfungen.

Wo Batch passt – und wo nicht

POST /check/sanctions_pep/batch akzeptiert mehrere unabhängige Prüfziele und unterstützt request_item_id für die Korrelation auf Elementebene. Der Endpunkt macht aus diesen Prüfungen keine native Transaktion mit Transaktionsreferenz, verbundenen Parteien, Transaction-Run-ID, Abruf anhand der Transaktionsreferenz oder einer Beziehung zu Transaktionsfällen und Webhooks.

CSV-Prüfungen eignen sich ebenfalls für definierte große Datenbestände. Sie bilden keine dritte Architektur für die Transaktionsverantwortung und sollten nicht mit verhaltensbasiertem Transaction Monitoring verwechselt werden. Nutzen Sie den Leitfaden API- oder Batch-Sanktionsprüfung, wenn zwischen ereignisgesteuerter Prüfung und einer Bestandsprüfung entschieden werden soll.

Compliance-Umfang und Zahlungsentscheidungen bleiben beim Kunden

Die von einer API unterstützten Parteienrollen bestimmen nicht, welche Parteien geprüft werden müssen. Maßgeblich für den Umfang sind die anwendbaren Sanktionsregime, die Exposition des Unternehmens und seine dokumentierte Richtlinie. US-amerikanische Bankenleitlinien stellen OFAC-Kontrollen beispielsweise in den Kontext des Risikoprofils, der Produkte, Kunden, Transaktionen, geografischen Gebiete und verfügbaren Technologie eines Instituts; daraus sollte keine allgemeingültige Regel für jede Branche oder jedes Land abgeleitet werden.

Ein Prüftreffer ist ein Signal zur weiteren Bewertung, nicht automatisch ein bestätigter Treffer oder eine zwingende Zahlungsentscheidung. Auch eine Antwort ohne Treffer ist keine allgemeingültige rechtliche Erlaubnis: Sanktionen können Eigentum, Kontrolle, Genehmigungen, Ausnahmen und Sachverhalte betreffen, die über einen einfachen Abgleich gelisteter Namen hinausgehen.

Checklynx stellt Prüf- und Workflow-Infrastruktur bereit. Der Kunde legt fest, welche Transaktionen und Parteien in den Umfang fallen, stellt relevante Daten bereit, bewertet mögliche Treffer und bleibt für den Umgang mit Zahlungen sowie rechtliche oder meldebezogene Entscheidungen verantwortlich. Weitere Hinweise zur Kontrollgestaltung bietet der Praxisleitfaden zur Sanktionsprüfung.

Checkliste für die Implementierung der Zahlungsprüfung

Häufig gestellte Fragen

Ist die Sanctions & PEP API zustandslos?

Die belastbare Architekturaussage lautet, dass POST /check/sanctions_pep weder einen Kunden noch einen Fall oder ein dokumentiertes Checklynx-Transaction-Run-Objekt erstellt. Der Kunde verantwortet den Transaktions- und Workflowdatensatz. Der öffentliche Vertrag begründet nicht, dass Checklynx buchstäblich keinerlei Backend-Speicherung oder Betriebsprotokollierung vornimmt; eine absolute Garantie der „Zustandslosigkeit“ würde daher über die Dokumentation hinausgehen.

Kann transaction_reference_id doppelte Transaktionsläufe verhindern?

Nein. Die Kennung ist eine nicht eindeutige fachliche Referenz des Kunden und kein Idempotenzschlüssel. Jeder Aufruf von POST /transactions erstellt einen neuen Lauf. Speichern Sie die zurückgegebene Lauf-id und implementieren Sie kundenseitig Duplikatschutz und Abgleich.

Erstellt jeder Transaktionstreffer einen Checklynx-Fall?

Nein. case_id kann null sein. Der aktuelle Vertrag unterstützt für anwendbare handlungsrelevante Ergebnisse die synchrone Erstellung oder Verknüpfung eines Falls. Die Integration sollte jedoch nicht versprechen, dass jeder Treffer automatisch einen Fall erzeugt.

Prüft der Transaktionsendpunkt die Bankkontonummer?

Beim derzeit dokumentierten bank_account-Instrument wird der BIC für die Sanktionsidentitätsprüfung verwendet. Die Kontonummer wird als unterstützender Nachweis aufbewahrt, derzeit jedoch weder geparst noch per Prüfsumme validiert oder selbst geprüft.

Gibt es für jede direkte Antwort der Sanctions & PEP API einen Webhook?

Der aktuelle öffentliche Ereigniskatalog dokumentiert keinen eigenständigen Abschluss-Webhook für POST /check/sanctions_pep. Das dokumentierte Transaktionsereignis betrifft einen neu eröffneten Transaction-Screening-Fall, nicht jeden Prüfaufruf.

Entscheidet eine der APIs, ob eine Zahlung freigegeben oder gestoppt wird?

Nein. Der Kunde verwendet Prüfergebnisse innerhalb seiner Richtlinien sowie seines Prüf- und Rechtsrahmens. Ein möglicher Treffer muss bewertet werden; die richtige Maßnahme für die Transaktion hängt vom anwendbaren Regime und den konkreten Umständen ab.

Wählen Sie das API-Modell passend zu Ihrem führenden System

Nutzen Sie Checklynx Transaction Screening, wenn Transaktionsparteien, Prüfergebnisse und Prüfungsnachweise in einem dauerhaften Prüflauf verbunden bleiben sollen. Nutzen Sie die Sanctions & PEP API, wenn Ihre eigene Plattform den Transaktionsworkflow vorhält und Checklynx die direkte Prüfantwort bereitstellt.

Die Wahl sollte vor der Implementierung ausdrücklich getroffen werden: Sie bestimmt Kennungen, Persistenz, Mehrparteienorchestrierung, Fallübergabe, Duplikatschutz und die Nachweise, die jedes System aufbewahren muss.