Standards:IG Scheme CreditorInformationReport

Cette page est à l'état de validation.
Elle est en cours de révision par les instances officielles, et devrait devenir une norme définitive prochainement.

These implementation rules shall be applied in accordance with ISO20022 and SEPA own implementation rules. Thus, unless explicitly specified, data contained within a field or XML structure of a SEPAmail message must comply with the constraints related to the equivalent field or XML structure in ISO20022 or SEPA messages.
for an explanation of the color coding used in the tables below, see this page
for general rules applying to all fields, see this page
for business rules directing these IG, see this page

Introduction

This document describes the contents of the SEPAmail message used to send information about a icqx@scheme-registered creditor.

The full name of this message is sepamail_message_scheme_CreditorInformationReport.

This message is generated and sent by the scheme or a QXOO, as a reply to a CreditorInformationRequest message.

Its exact contents depends on the request :

if the creditor is known, A3 must always hold its ICQXCard.
if a specific ServiceCard was requested (SvcCard (A3) present in InformationRequest message)
- if the requested ServiceCard exists and is active, if is returned in SvcCard (A4) and Status (A2) contains "OK".
- if it does not exist (or if the creditor is unknown), SvcCard is omitted and Status (A2) contains "NO_SRVC".
if no specific ServiceCard was requested (SvcCard (A3) omitted in InformationRequest message), all active ServiceCards are returned in as many A4 elements as necessary. If the creditor is unknown or has no active ServiceCards, A4 is omitted. Status (A2) contains "NO_ICQX" or "OK" depending on the case.

This message is not based upon any existing ISO schema. It carries a SEPAmail-specific structure : an ICQXCard. </svnig>

Message root

</svnig>

Mult	Message Element	SEPAmail requirement
[1..1]	CreditorInformationReport

</svnig>

Internal abstraction level

To facilitate upgrades, an abstraction level has been inserted at the root of this element.

The actual contents of the CreditorInformationReport element must be any one of the sepamail_creditor_information_report_xxx structures. </svnig>

Mult	Message Element	SEPAmail requirement
[1..1]	sepamail_creditor_information_report_001	First version of the message

</svnig>

Message Body

</svnig>

Ref	Mult	Message Element	SEPAmail requirement
A1	[1..1]	+ RequestId	Unique identifier, which must to match the one in InformationRequest (element A1).
A2	[1..1]	+ Status	Status of the report. Possible values are OK: the creditor is known, and, if a ServiceCard was requested, it exists. NO_SRVC: the creditor is known, but has no such ServiceCard. NO_ICQX: this identifier is unknown.
A3	[0..1]	+ ICQXCard	The ICQXCard of the creditor, if it exists (values OK or NO_SRVC for A2). Seee below for detailed contents.
A4	[0..n]	+ SvcCard	If one ServiceCard was requested, only one element for this card if it exists (value OK for A2). If all ServiceCards were requested, one element per active ServiceCard.
A4.1	[1..1]	++ SvcName	Name of the service associated with the ServiceCard, among "RUBIS_inscription", "RUBIS_emission" ...
A4.2	[1..1]	++ Active	In this message, only active cards may be sent. This field must then be true.
A4.3	[1..1]	++ Scope	Scope of the card, may be "local" or "global".
A4.4	[1..n]	++ QXBAN	QXBAN associated with the service.
A4.5	[0..3]	++ customerHelp	Elements allowing customer to find the creditor reference.
A4.5.1	[1..1]	+++ identifierName	Name of the reference to find
A4.5.2	[1..1]	+++ helpText	Textual description of the location of this reference.
A4.5.3	[0..n]	+++ helpImage	Pictures illustrating the text.

</svnig>

ICQXCard

Here is the exact contents of this structure.

Ref	Mult	Message Element	SEPAmail requirement
I	[1..1]	+ ICQXCard
I1	[0..1]	++ ICQX	Mandatory in all messages, except CreditorCreationRequest where it MUST be absent.
I2	[1..1]	++ BIC	BIC of the bank issuing the request
I3	[1..1]	++ Identity
I3.1	[1..1]	+++ PartyName	Name by which a party is known and which is usually used to identify that party. For a company, this must be the registered name.
I3.2	[0..1]	+++ DisplayName	Name by which the party is designated (can be a commercial name, an alias ...). Defaults to PartyName (I3.1).
I3.3	[0..1]	+++ Logo
I3.4	[0..1]	+++ Thumbnail
I3.5	[1..1]	++ PostalAddress	Information that locates and identifies the address of the Party, as defined by postal services and at which the business is legally domiciled.
I3.5.1	[0..1]	+++ AddressType	Code
I3.5.2	[0..1]	+++ Department	Text
I3.5.3	[0..1]	+++ SubDepartment	Text
I3.5.4	[0..1]	+++ StreetName	Text
I3.5.5	[0..1]	+++ BuildingNumber	Text
I3.5.6	[0..1]	+++ PostCode	Text
I3.5.7	[0..1]	+++ TownName	Text
I3.5.8	[0..1]	+++ CountrySubdivision	Text
I3.5.9	[0..1]	+++ Country	Code
I3.5.10	[0..7]	+++ AddressLine	Text
I4	[1..1]	++ Identification
I4.1	[1..n]	+++ OrgId
I4.1.1	[1..1]	++++ Id	Identification data (SIREN, legal structure ...)
I4.1.2	[0..1]	++++ SchmeNm
I4.1.3	[0..1]	++++ Issr	Mandatory, type of data. Allowed values are SIRET SIREN APE TVA_intracomm legal_structure other
I5	[1..1]	++ Validity
I5.1	[1..1]	+++ ValidStartDate	ISO format
I5.2	[1..1]	+++ ValidEndDate	ISO format
I5.3	[1..1]	+++ LastUpdateDate	ISO format
I5.4	[0..1]	+++ Test	True if this is a testing account [usefulness to be confirmed]

</svnig>

Standards:IG Scheme CreditorInformationReport

Introduction

Message root

Internal abstraction level

Message Body

ICQXCard

Navigation menu

Search