Dokumentation der API

Kreditüberprüfungen und Statusänderungen

Die Portfolioüberwachung verschiebt ein Engagement zwischen Grün, Gelb, Rot und Noch kein Score, wenn sich die Nachweise ändern. Diese Seite erklärt, was eine Statusänderung aussagt, welche Änderungen auf eine Kenntnisnahme warten und wie Ihr Team seine eigene Kreditüberprüfung eines Engagements festhält. Alles hier steht im Dashboard, über die API und für Assistenten mit KI über MCP zur Verfügung.

Die Status

Ein Engagement trägt einen von sechs Status, im Dashboard, in den Berichten und in dieser Dokumentation gleich benannt. API und MCP liefern den Wert in Klammern als status.

  • Grün, Gelb und Rot (green, amber, red), der bewertete Kreditstatus.
  • Noch kein Score (insufficient), bewertet, aber von dem, was die angebundenen Quellen für das Unternehmen liefern können, wurde zu wenig beobachtet, um es zu bewerten. Liegt zu dem Unternehmen kein Jahresabschluss vor, sagen das die Unternehmensseite und die Unterlage für das Kreditkomitee, und API und MCP liefern no_status_reason als no_accounts, denn der Jahresabschluss trägt den größten Teil des Gewichts eines Unternehmensstatus.
  • Noch nicht bewertet (not_assessed), für das Engagement liegt noch keine Einschätzung vor.
  • Einzelunternehmen (sole_trader), nach den Angaben seines Registers das Geschäft einer natürlichen Person. Es wird nie bewertet, seine Identität und seine Kreditüberprüfung bleiben.

Warum sich ein Status bewegt hat

Jede Statusänderung nennt ihre Ursache. Die Ursache wird aus den beiden Einschätzungen abgeleitet, die die Änderung vergleicht. Beide bleiben dauerhaft als Historie erhalten, und die Ableitung folgt einer festen Regel ohne jedes Modell.

  • Die Treiber sind die Signale, deren Änderung den Status bewegt hat, jeweils mit ihrem Band davor und danach und den Kennungen der Nachweise, auf denen ihr neuer Stand beruht. Hat sich der Status verschlechtert, sind die Treiber die Signale, die ungünstiger wurden oder eine Übersteuerung ausgelöst haben, sowie die Signale, die nicht mehr grün bewertet werden, denn wegfallende entlastende Nachweise erhöhen den Score. Hat er sich verbessert, gilt das Spiegelbild. Ein Wechsel zu Noch kein Score nennt die Signale, die nicht mehr beobachtet werden konnten. Haben alle Treiber ihre Bewertung verloren, nennt die Änderung ihre Zahl, zum Beispiel 7 Signale werden nicht mehr bewertet. Hat der führende Treiber sein Band behalten und nur seine Übersteuerung geändert, sagt die Änderung, was die Übersteuerung jetzt bewirkt, zum Beispiel Insolvenzverfahren erzwingt jetzt Rot.
  • Der Registereintrag hinter dem führenden Treiber wird mit seinem Register und seiner Referenz genannt, wenn ein Eintrag dahintersteht. Ein Signal, das sich bewegt hat, weil ein Nachweis jetzt fehlt, zitiert nichts, und die Änderung sagt das, statt eine Quelle zu erfinden.
  • Bewertungsregeln geändert steht an erster Stelle, wenn sich die Bewertungslogik oder das Bewertungsschema zwischen den beiden Einschätzungen unterscheidet. Das Standardschema und ein von Ihrem Team gespeichertes Schema gelten als verschiedene Schemata; eine Einschätzung mit Noch kein Score bewertet nichts und wird daher nie nach Schema verglichen. Die Bewegung kann dann aus dem Regelwerk kommen und nicht vom Kreditnehmer.

Je Änderung werden höchstens fünf Treiber genannt, die übrigen werden gezählt. Die Kennungen der beiden Einschätzungen werden mit der Ursache ausgeliefert, sodass jede Aussage an der vollständigen Signalaufstellung geprüft werden kann. Lässt sich eine der beiden Einschätzungen nicht lesen, sagt die Änderung Ursache nicht verfügbar und behauptet nichts weiter.

Neuaufnahmen sind keine Änderungen

Die erste Einschätzung eines Engagements bei der Aufnahme in den Bestand erscheint als In den Bestand aufgenommen mit ihrem ersten Status und, bei Gelb oder Rot, den Signalen, die ihn gesetzt haben. Eine Neuaufnahme ist keine Änderung. Sie wartet nie auf eine Kenntnisnahme und zählt nicht zu den Statusänderungen der letzten 30 Tage, bleibt aber in der Zahl aller Übergänge der letzten 30 Tage enthalten.

Aus dem Bestand nehmen

Eine Analystin oder ein Analyst nimmt ein Unternehmen auf seiner Seite mit Aus dem Bestand entfernen und einem Grund aus dem Bestand, Versehentlich hinzugefügt oder Engagement beendet. Werden zwei Einträge desselben Unternehmens, die der Bestand hielt, zu einem Unternehmen zusammengeführt, verlässt der zweite Eintrag den Bestand mit dem Grund Dasselbe Unternehmen wie ein anderer Eintrag, und das Unternehmen bleibt einmal im Bestand. Die Statusänderungen zeigen dann Aus dem Bestand entfernt mit dem Status, auf dem das Unternehmen stand, und hinter der Aufklappzeile, wer es entfernt hat und warum. Ein erneut aufgenommenes Unternehmen erscheint als Wieder in den Bestand aufgenommen. Diese Einträge sind die Geschichte des Bestands und keine Statusänderungen, sie warten daher nie auf eine Kenntnisnahme und lösen nie eine Benachrichtigung aus. Frühere Einschätzungen, Statusänderungen und Überprüfungen des Unternehmens bleiben erhalten, und eine erneute Aufnahme setzt denselben Eintrag fort.

Kenntnisnahme von Änderungen

Eine Analystin oder ein Analyst nimmt eine Statusänderung zur Kenntnis, sobald sie geprüft ist, einzeln oder alle auf der Seite gezeigten offenen Änderungen mit einer Aktion. Gestempelt werden nur echte, noch offene Änderungen des eigenen Teams; Administratoren können teamübergreifend zur Kenntnis nehmen. Jede Kenntnisnahme schreibt ihren eigenen Eintrag ins Aktivitätsprotokoll, gleich auf welchem Weg sie erfolgt ist.

Der Überprüfungsdatensatz

Jedes Engagement trägt seinen eigenen Datensatz zur Kreditüberprüfung vom Tag an, an dem es in den Bestand kommt. An diesem Tag ist das Mitglied, das das Unternehmen aufgenommen hat, für die erste Überprüfung verantwortlich, die ein Jahr später fällig wird, und der Datensatz lautet In den Bestand aufgenommen (added in der API), bis eine Analystin oder ein Analyst eine Überprüfung erfasst. Jede weitere Überprüfung setzt eine Analystin oder ein Analyst.

  • Einstufung, eine von Geprüft, kein Handlungsbedarf; Beobachtungsliste; Intensivbetreuung; An die Kreditentscheidung eskaliert. Beobachtungsliste und Eskalation an die Kreditentscheider folgen EBA GL/2020/06 Randnummern 270, 272 und 275, die Intensivbetreuung folgt MaRisk BTO 1.2.4.
  • Notiz, freier Text mit bis zu 2.000 Zeichen.
  • Verantwortlich, ein aktuelles Mitglied Ihres Arbeitsbereichs, das die Überprüfung selbst erfassen könnte, also ein Mitglied des Teams des Engagements mit der Rolle Analyse oder Compliance oder eine Administratorin oder ein Administrator des Arbeitsbereichs. Die Auswahl bietet genau diese Mitglieder mit Namen an; ein Mitglied, dessen Konto entfernt wurde, wird nicht mehr angeboten und abgelehnt.
  • Nächste Überprüfung, zwischen heute und einem Jahr ab heute, denn MaRisk BTO 1.2.2 verlangt mindestens jährlich eine Beurteilung der Adressenausfallrisiken.

Eine neue Überprüfung wird zur geltenden Überprüfung des Engagements, die früheren bleiben erhalten. Die Historie wird nur fortgeschrieben. Nichts wird je geändert oder gelöscht, und eine Korrektur ist eine neuere Überprüfung. Nur lesende Mitglieder sehen jede Überprüfung ihres Bestands und erfassen keine.

Fällige Überprüfungen

Eine Überprüfung ist überfällig, wenn das Datum der nächsten Überprüfung der geltenden Überprüfung verstrichen ist. Die Portfolioseite listet überfällige Überprüfungen und solche, die in den nächsten zwei Wochen fällig werden, die frühesten zuerst, und zählt die Engagements, die nie überprüft wurden, darunter jedes, dessen einziger Datensatz der vom Tag seiner Aufnahme ist. Die Liste liest dasselbe Team wie die übrige Portfolioseite; werden alle Teams gezeigt, nennt jede Zeile ihr Team. Datumsangaben werden in UTC verglichen.

Wo welcher Teil ausgeliefert wird

  • Dashboard. Der Feed der Statusänderungen zeigt jede Ursache in einer Zeile und bietet die Kenntnisnahme an; die Unternehmensseite trägt den Überprüfungsdatensatz und seine Historie; die Portfolioseite listet die fälligen Überprüfungen.
  • API. GET /v1/portfolio/transitions trägt je Zeile die cause; GET /v1/portfolio trägt je Engagement die geltende review und review_overdue; GET /v1/portfolio/summary zählt transitions_30d, status_changes_30d und reviews_overdue; GET /v1/portfolio/{exposure_id}/reviews liefert die Historie, in der der Datensatz vom Tag der Aufnahme added lautet; GET /v1/portfolio/reviews-due listet die fälligen Überprüfungen. Verantwortliche und Prüfende sind Identitäten von Mitgliedern und bleiben im Dashboard.
  • MCP. portfolio_overview liefert mit den Übergängen ihre Ursachen und die Zahl überfälliger Überprüfungen; portfolio_book liefert je Engagement die geltende Überprüfung; exposure_review_history liefert die Historie eines Engagements; portfolio_reviews_due listet die fälligen Überprüfungen.
  • Unterlage für das Kreditkomitee. Der Abschnitt zur Kreditüberwachung druckt die geltende Überprüfung mit Einstufung, Verantwortlichen und nächstem Überprüfungsdatum sowie jede jüngere Statusänderung mit ihrer Ursache.