<?xml version="1.0" encoding="UTF-8"?>
<!-- Mit XMLSpy v2011 rel. 2 (x64) (http://www.altova.com) von STUZZA (STUZZA) bearbeitet -->
<!-- edited with XMLSpy v2015 sp2 (x64) (http://www.altova.com) by Helmut Biely (self employed) -->
<xs:schema xmlns="http://www.stuzza.at/MBS/V7.0.04/Request" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" targetNamespace="http://www.stuzza.at/MBS/V7.0.04/Request" elementFormDefault="qualified" attributeFormDefault="unqualified">
	<xs:import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="xmldsig-core-schema.xsd"/>
	<!-- ********************************************************************************-->
	<!-- ***     Änderungen gegenüber Version 6001                                ***-->
	<!-- ***     o MsgId maxLen = 35                                                           ***-->
	<!-- ***     o Imageanforderung gelöscht                                              ***-->
	<!-- ***     o Anmerkung zu EBZ Anforderung überarbeitet                  ***-->
	<!-- ***     o Anmerkung zu EBZ  TpVerf SubTp ergänzt                      ***-->
	<!-- ***     o CAMT086  in  SubTpTyp1 ergänzt                                     ***-->
	<!-- ******************************************************************************** -->
	<!-- ***     Änderungen gegenüber Version 7.0.01                               ***-->
	<!-- ***     o BIC aus  AcctType und AcctType1  entfernt                     ***-->
	<!-- ******************************************************************************** -->
	<!--  ***  Änderung gegenüber Version  7.0.03                                     ***-->
	<!--  ***  o keine - ausschließlich Anpassung der Version auf 7.0.04  ***-->
	<!--  ********************************************************************************-->
	<!--  ***  Änderung gegenüber VD=08.04.2016                                     ***-->
	<!--  ***  o Kommentar zu KTO in Weiche vor Datumsangaben             ***-->
	<!--  ********************************************************************************-->
	<!--  ***  Änderung gegenüber VD=04.05.2016                                     ***-->
	<!--  ***  o Berücksichtigung von ISOSTS in RstrtDtTm bei Typ KTO      ***-->
	<!--  ********************************************************************************-->
	<!--  ***  Änderung gegenüber VD=25.07.2016                                     ***-->
	<!--  ***  o Einfügung MT942 in ReqInfType2-Weiche und RstrtDtTm     ***-->
	<!--  ********************************************************************************-->
	<xs:attribute name="versiondate" fixed="05.12.2016">
		<xs:annotation>
			<xs:documentation xml:lang="de">Versionsdatum dieses Schemas</xs:documentation>
		</xs:annotation>
	</xs:attribute>
	<xs:element name="Document" type="Document">
		<xs:annotation>
			<xs:documentation>Root Element</xs:documentation>
		</xs:annotation>
	</xs:element>
	<xs:complexType name="AcctType">
		<xs:sequence>
			<xs:element name="IBAN" type="IBANIdentifier"/>
		</xs:sequence>
		<xs:attribute name="Ccy" type="CurrencyCode" default="EUR">
			<xs:annotation>
				<xs:documentation>Währung des Kontos</xs:documentation>
			</xs:annotation>
		</xs:attribute>
	</xs:complexType>
	<xs:complexType name="AcctType1">
		<xs:choice>
			<xs:element name="IBAN" type="IBANIdentifier">
				<xs:annotation>
					<xs:documentation>IZV: Ausschliesslich AT-IBANs sind gültig!</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:element name="NonDmstAcct" type="SWIFTAcctTp">
				<xs:annotation>
					<xs:documentation>AZV: es sind alle Definitionen zulässig, die bei der Anlage eines SWIFT Kontos in MBS auftreten dürfen. Dies ist eine verkürzte Version gegenüber den Kontoverbindungen die ein AustrianN-pain001 erlaubt .</xs:documentation>
				</xs:annotation>
			</xs:element>
		</xs:choice>
		<xs:attribute name="Ccy" type="CurrencyCode">
			<xs:annotation>
				<xs:documentation>Währung des Kontos</xs:documentation>
			</xs:annotation>
		</xs:attribute>
	</xs:complexType>
	<xs:simpleType name="BookgDtInd">
		<xs:restriction base="xs:boolean"/>
	</xs:simpleType>
	<xs:simpleType name="BtchCtrType">
		<xs:annotation>
			<xs:documentation>Laufende Nummer des Request mit 1 beginned,  eindeutig über das gesamte Dokument. Nicht notwendiger Weise lückenlos.</xs:documentation>
		</xs:annotation>
		<xs:restriction base="xs:positiveInteger">
			<xs:totalDigits value="5"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="CountryCode">
		<xs:restriction base="xs:string">
			<xs:pattern value="[A-Z]{2,2}"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="CurrencyCode">
		<xs:restriction base="xs:string">
			<xs:length value="3"/>
			<xs:pattern value="[A-Z]*"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:complexType name="Document">
		<xs:sequence>
			<xs:element name="MBS_Request_Message" type="MBS_Request_Message_Type"/>
		</xs:sequence>
	</xs:complexType>
	<xs:simpleType name="DocType">
		<xs:restriction base="xs:boolean"/>
	</xs:simpleType>
	<xs:complexType name="DspsrType">
		<xs:sequence>
			<xs:element name="DspsrNm">
				<xs:annotation>
					<xs:documentation>Name des signierenden Verfügers.</xs:documentation>
				</xs:annotation>
				<xs:simpleType>
					<xs:restriction base="Max35Text"/>
				</xs:simpleType>
			</xs:element>
			<xs:element name="DspsrNbr" type="DspsrNbrType">
				<xs:annotation>
					<xs:documentation>Zugehörige Verfügernummer </xs:documentation>
				</xs:annotation>
			</xs:element>
		</xs:sequence>
	</xs:complexType>
	<xs:simpleType name="DspsrNbrType">
		<xs:restriction base="Max17Text">
			<xs:pattern value="[A-Z0-9\-]*"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="DtType">
		<xs:restriction base="xs:date"/>
	</xs:simpleType>
	<xs:simpleType name="EbzIdType">
		<xs:restriction base="xs:string">
			<xs:length value="16"/>
			<xs:pattern value="[A-Z0-9\-]*"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:complexType name="GrpHdrType">
		<xs:sequence>
			<xs:element name="MsgId">
				<xs:annotation>
					<xs:documentation>Eindeutige Identifikation der Nachricht. Aufbau: Stellen 1 bis 16 Timestamp im Format  JJJJMMTTHHMMSShh, 4   Zufallszeichen zwingend bis zu 15 weitere Zufallszeichen optional </xs:documentation>
				</xs:annotation>
				<xs:simpleType>
					<xs:restriction base="MsgIdType"/>
				</xs:simpleType>
			</xs:element>
		</xs:sequence>
	</xs:complexType>
	<xs:simpleType name="IBANIdentifier">
		<xs:restriction base="xs:string">
			<xs:pattern value="[a-zA-Z]{2,2}[0-9]{2,2}[a-zA-Z0-9]{1,30}"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="IndCmpType">
		<xs:restriction base="xs:boolean"/>
	</xs:simpleType>
	<xs:simpleType name="ImgType">
		<xs:restriction base="xs:boolean"/>
	</xs:simpleType>
	<xs:simpleType name="ISODateTime">
		<xs:restriction base="xs:dateTime"/>
	</xs:simpleType>
	<xs:simpleType name="ImgTpType">
		<xs:restriction base="xs:string">
			<xs:enumeration value="EER"/>
			<xs:enumeration value="BMR"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="Max4Text">
		<xs:restriction base="xs:string">
			<xs:minLength value="1"/>
			<xs:maxLength value="4"/>
			<xs:whiteSpace value="collapse"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="Max17Text">
		<xs:restriction base="xs:string">
			<xs:minLength value="1"/>
			<xs:maxLength value="17"/>
			<xs:whiteSpace value="collapse"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="Max34Text">
		<xs:restriction base="xs:string">
			<xs:minLength value="1"/>
			<xs:maxLength value="34"/>
			<xs:whiteSpace value="collapse"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="Max35Text">
		<xs:restriction base="xs:string">
			<xs:minLength value="1"/>
			<xs:maxLength value="35"/>
			<xs:whiteSpace value="collapse"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="Max70Text">
		<xs:restriction base="xs:string">
			<xs:minLength value="1"/>
			<xs:maxLength value="70"/>
			<xs:whiteSpace value="collapse"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:complexType name="MBS_Request_Message_Type">
		<xs:sequence>
			<xs:element name="GrpHdr" type="GrpHdrType"/>
			<xs:element ref="MBS_Request_Message_EBZ" minOccurs="0">
				<xs:annotation>
					<xs:documentation>MBS Anforderungsmessage EBZ für die Anforderung von einem oder mehreren EBZ.

Ein EBZ der MBS V.7.0 darf nur an einen V.7.0 Client geliefert werden. Ebenso darf an einen V.6.0 Client nur ein EBZ der V.6.0 angeboten werden. Soll ein Austausch von EBZ über die beiden Versionen hinweg ermöglicht werden, so hat der BR für eine entsprechende korrekte Konvertierung von V.6.0 auf V.7.0 und vice versa Sorge zu tragen. Diese Konvertierung ist ein optionales Service. Siehe auch Kapitel 4.9 der Einführung.</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:element ref="MBS_Request_Message_KOP" minOccurs="0">
				<xs:annotation>
					<xs:documentation>MBS Anforderungsmessage KOP für die Anforderung von Auftragskopien  (XML oder MT101).</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:element ref="MBS_Request_Message_KTO" minOccurs="0">
				<xs:annotation>
					<xs:documentation>MBS Anforderungsmessage KTO für die Anforderungen von Kontoinformationen, die in SubTp spezifiziert sind. wie z.B. Auszüge, Belege, Retourdatenträger, Spesenaufstellungen und ISO-Statusmessages</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:element ref="MBS_Request_Message_PDF" minOccurs="0">
				<xs:annotation>
					<xs:documentation>MBS Anforderungsmessage PDF für die Anforderung elektronischer Kontoauszüge im PDF-Format (eKA) . </xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:element name="XMLDSig">
				<xs:annotation>
					<xs:documentation>Die Anforderung ist mittels XMLDSig (PIN des anfordernden Verfügers ) zu autorisieren.

Die XMLDSig erstreckt sich dabei über alle vorangehenden Sub-Messages (EBZ, IMG, KOP, etc.)  bis AddtlSgntrInf.</xs:documentation>
				</xs:annotation>
				<xs:complexType>
					<xs:sequence>
						<xs:element name="AddtlSgntrInf" type="SgntrInfType">
							<xs:annotation>
								<xs:documentation>Zusatzinformationen zur Signatur, diie mit zu signieren sind.</xs:documentation>
							</xs:annotation>
						</xs:element>
						<xs:element ref="ds:Signature"/>
					</xs:sequence>
				</xs:complexType>
			</xs:element>
		</xs:sequence>
	</xs:complexType>
	<xs:element name="MBS_Request_Message_EBZ">
		<xs:annotation>
			<xs:documentation>MBS Anforderungsmessage EBZ: 
Anforderung von EBZ</xs:documentation>
		</xs:annotation>
		<xs:complexType>
			<xs:sequence>
				<xs:element name="ReqInf" type="ReqInfType" maxOccurs="unbounded">
					<xs:annotation>
						<xs:documentation>Eine EBZ –Anforderung kann entweder über die Angabe einer Identifikationsnummer eines EBZ (TpEbz) oder über einen, dem EBZ zugeordneten Verfüger (TpVerf) erfolgen.</xs:documentation>
					</xs:annotation>
				</xs:element>
			</xs:sequence>
		</xs:complexType>
	</xs:element>
	<xs:element name="MBS_Request_Message_KOP">
		<xs:annotation>
			<xs:documentation>MBS Anforderungsmessage KOP: 
Anforderung von Auftragskopien
 (XMLoder MT101).</xs:documentation>
		</xs:annotation>
		<xs:complexType>
			<xs:sequence>
				<xs:element name="ReqInf" type="ReqInfType_1" maxOccurs="unbounded">
					<xs:annotation>
						<xs:documentation>Werden  sensitive Auftragsbestände (z.B. Gehaltsdaten) als Kopie angefordert, so kann der BR die Anforderung mit Status 745 ablehnen.</xs:documentation>
					</xs:annotation>
				</xs:element>
			</xs:sequence>
		</xs:complexType>
	</xs:element>
	<xs:element name="MBS_Request_Message_KTO">
		<xs:annotation>
			<xs:documentation>MBS Anforderungsmessage KTO: 
Anforderungen von Auszügen, Belegen, Retourdatenträger, ISO-Statusmessages etc.

Die Art der gewünschten Kontoinformation wird in SubTp spezifiziert.</xs:documentation>
		</xs:annotation>
		<xs:complexType>
			<xs:sequence>
				<xs:element name="ReqInf" type="ReqInfType_2" maxOccurs="unbounded">
					<xs:annotation>
						<xs:documentation>Ein oder mehrere Anfragen  unterschiedlichen Subtyps</xs:documentation>
					</xs:annotation>
				</xs:element>
			</xs:sequence>
		</xs:complexType>
	</xs:element>
	<xs:element name="MBS_Request_Message_PDF">
		<xs:annotation>
			<xs:documentation>MBS Anforderungsmessage PDF: 
Anforderung von PDF Auszügen
</xs:documentation>
		</xs:annotation>
		<xs:complexType>
			<xs:sequence>
				<xs:element name="ReqInf" type="ReqInfType_3" maxOccurs="unbounded">
					<xs:annotation>
						<xs:documentation>Spezifikation der konkreten Anforderung der PDF Auszüge optional ergänzt mit Belegen und/oder Images, Signatur etc.

Sämtliche Anforderungsarten sind optional in dem Sinne, dass es kein definiertes Mindestprofil gibt, das von allen Bankrechnern unterstützt werden muss. Nicht unterstützte Optionen sind vom Bankrechner mit Status 700 "Anforderung nicht unterstützt" abzulehnen.

Werden auf Wunsch für einen Bankrechner Defaultwerte für die Attribute zu ReqInf eingestellt, so sind diese so zu gestalten, dass sie vom Kunden bewusst überschrieben werden können, auch auf die Gefahr hin, dass die Kundenwahl dann zu einer Ablehnung mangels Unterstützung führt.</xs:documentation>
					</xs:annotation>
				</xs:element>
			</xs:sequence>
		</xs:complexType>
	</xs:element>
	<xs:simpleType name="MsgIdType">
		<xs:restriction base="xs:string">
			<xs:whiteSpace value="collapse"/>
			<xs:minLength value="20"/>
			<xs:maxLength value="35"/>
			<xs:pattern value="2[0-9]{15}[A-Z0-9]{4,}"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="MsgRefType">
		<xs:restriction base="Max35Text"/>
	</xs:simpleType>
	<xs:complexType name="ReqInfType">
		<xs:sequence>
			<xs:element name="BtchCtr" type="BtchCtrType">
				<xs:annotation>
					<xs:documentation>Laufende Nummer des Request mit 1 beginned anlässlich des ersten Vorkommens des BtchCtrType,  eindeutig über das gesamte Dokument, also über alle Requesttypen hinweg. Nicht notwendiger Weise lückenlos; wichtig ist die Eindeutigkeit innerhalb der MsgId zwecks späterer Referenzierung.</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:choice>
				<xs:element name="TpEbz" type="TpEbzType">
					<xs:annotation>
						<xs:documentation>Anforderung von konkreten 
EBZ über Id-nummer</xs:documentation>
					</xs:annotation>
				</xs:element>
				<xs:element name="TpVerf" type="TpVerfType">
					<xs:annotation>
						<xs:documentation>Anforderung von EBZ über Verfüger. Die zutreffende Verfügernummer ist der Autorisierung zu entnehmen.</xs:documentation>
					</xs:annotation>
				</xs:element>
			</xs:choice>
		</xs:sequence>
	</xs:complexType>
	<xs:complexType name="ReqInfType_1">
		<xs:sequence>
			<xs:element name="BtchCtr" type="BtchCtrType">
				<xs:annotation>
					<xs:documentation>Laufende Nummer des Request mit 1 beginned anlässlich des ersten Vorkommens des BtchCtrType,  eindeutig über das gesamte Dokument, also über alle Requesttypen hinweg. Nicht notwendiger Weise lückenlos; wichtig ist die Eindeutigkeit innerhalb der MsgId zwecks späterer Referenzierung.</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:element name="EbzId">
				<xs:annotation>
					<xs:documentation>In EbzId ist die Identifikationsnummer jenes EBZ einzustellen, dessen Datenträger als Kopie angefordert werden. 
Ist EbzId das einzige Element der Anforderung, werden alle Datenträger (XML und MT101) dieses EBZ als Kopie angefordert.</xs:documentation>
				</xs:annotation>
				<xs:simpleType>
					<xs:restriction base="EbzIdType"/>
				</xs:simpleType>
			</xs:element>
			<xs:element name="MsgRef" type="MsgRefType" minOccurs="0">
				<xs:annotation>
					<xs:documentation>Mittels MsgRef wird die Anforderung auf die Kopie eines einzigen Datenträgers aus dem vorangehend definierten EBZ eingeschränkt.
In MsgRef ist dafür die Referenznummer aus Ref des SctnHdr des EBZ einzustellen. (Diese ist ident mit der MsgId des GrpHdr des zugehörigen XML-Datenträgers. Im Fall eines MT101 ist die MsgRef dem Feld20 zu entnehmen).
Sollen mehrere DT aus einem EBZ in Kopie angefordert werden, ist ReqInf zu wiederholen; damit ist auch eine eindeutige Referenzierung im Fall einer Statusantwort möglich, falls eine Kopie nicht erstellt werden kann.
</xs:documentation>
				</xs:annotation>
			</xs:element>
		</xs:sequence>
	</xs:complexType>
	<xs:complexType name="ReqInfType_2">
		<xs:sequence>
			<xs:element name="BtchCtr" type="BtchCtrType">
				<xs:annotation>
					<xs:documentation>Laufende Nummer des Request mit 1 beginned anlässlich des ersten Vorkommens des BtchCtrType,  eindeutig über das gesamte Dokument, also über alle Requesttypen hinweg. Nicht notwendiger Weise lückenlos; wichtig ist die Eindeutigkeit innerhalb der MsgId zwecks späterer Referenzierung.</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:element name="SubTp">
				<xs:annotation>
					<xs:documentation>Mit SubTp wird die eigentliche Art der angeforderten Kontoinformation festgelegt:
o MT940  SWIFT MT940 Kontoauszüge
o MT942  SWIFT MT942 Kontovormerkungen
o BELEG	Belegdaten zu MT940 Kontoauszügen
o DAAB  Informationen zu Daueraufträgen
o DEPOT Auszug eines WP Depots
o CREMUL Retourdatenträger im EDI
o DEBMUL Retourdatenträger im EDI
o CAMTnnn Kontoinformationen  ISO camt052, camt053 oder camt054
o CAMT086 Spesenaufstellung
o ISOSTS Statusnachricht im Format ISO 20022  Payment Status Report
</xs:documentation>
				</xs:annotation>
				<xs:simpleType>
					<xs:restriction base="SubTpType_1">
						<xs:maxLength value="7"/>
					</xs:restriction>
				</xs:simpleType>
			</xs:element>
			<xs:element name="Acct" type="AcctType1">
				<xs:annotation>
					<xs:documentation>Acct definiert das Konto, zu dem die Kontoinformationen gemäß SubTp angefordet werden.</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:choice minOccurs="0">
				<xs:annotation>
					<xs:documentation>Für Tp=Camt052 oder MT942 kann ein Wiederaufsetzdatum optional kodiert werden. Es ist jedoch nur für BR relevant, die einen inkrementellen MT942 oder Camt052 (siehe die Einführungsdokumentation) anbieten; sonst zu ignorieren. Alle anderen Sub-Felder dieser Weiche sind für Camt052 nicht zulässig.</xs:documentation>
				</xs:annotation>
				<xs:sequence>
					<xs:element name="StartDt" type="DtType">
						<xs:annotation>
							<xs:documentation>Mit StartDt wird das Beginndatum i.e. das Buchungsdatum, ab dem die gewünschten Informationen zu liefern sind, definiert.

Ist neben StartDt auch ein EndDt kodiert, so werden die in SubTp angegebenen  Kontoinformationen für das damit definierte Zeitfenster angefordert.

Ein in der Zukunft liegendes Anforderungsdatum ist unzulässig und wird vom Bankrechner abgelehnt. </xs:documentation>
						</xs:annotation>
					</xs:element>
					<xs:element name="EndDt" type="DtType" minOccurs="0">
						<xs:annotation>
							<xs:documentation>Bezieht  sich die Anforderung auf  einen konkreten Zeitraum, definiert EndDt das Ende des gewünschten Zeitfensters. EndDt muss größer oder gleich der in StartDt kodierten Darumsangabe sein, andernfalls ist mit negativen Status 708 zu reagieren. Aber Achtung: beim Eintragen in die lokale DB des Client dürfen eventuell vorhandene Einträge die hinter diesem Datum liegen nicht überschrieben werden.

Wird EndDt nicht kodiert, so sind alle Informationen von StartDt bis zum aktuellen Tagesdatum zu liefern.</xs:documentation>
						</xs:annotation>
					</xs:element>
				</xs:sequence>
				<xs:sequence>
					<xs:element name="StartStmtNb" type="StmtNumType">
						<xs:annotation>
							<xs:documentation>Mit StartStmtNb können Kontoinformationen alternativ zur Datumsangabe mittels Angabe der Auszugsnummer im Format JJJJNNNNN (z.B. 201200034) angefordert werden.
StartStmtNb ist nur für SubTp = Camt053, MT940 und BELEG zulässig. In allen anderen Fällen ist mit negativen Status 708 zu antworten. 
</xs:documentation>
						</xs:annotation>
					</xs:element>
					<xs:element name="EndStmtNb" type="StmtNumType" minOccurs="0">
						<xs:annotation>
							<xs:documentation>Mit EndStmtNb (Format siehe StartStmtNb) kann die Anforderung von Kontoinformationen bis zu einer bestimmten Auszugsnummer begrenzt werden. EndStmtNb muss größer oder gleich der in StartStmtNb angebenen Auszugsnummer sein, andernfalls ist mit negativen Status 708 zu reagieren. Aber Achtung: beim Eintragen in die lokale DB des Client dürfen eventuell vorhandene Einträge die hinter dieser Auszugsnummer liegen nicht überschrieben werden.

Wird EndStmtNb nicht kodiert, so sind die angeforderten Kontoinformationen bis zu der aktuell höchsten Auszugsnummer  zu liefern.
</xs:documentation>
						</xs:annotation>
					</xs:element>
				</xs:sequence>
				<xs:element name="RestrtDtTm" type="ISODateTime">
					<xs:annotation>
						<xs:documentation>RstrtDtTm dient der Angabe einer Wiederaufsetzreferenz, um eine lückenlose Information (Kontoauszugsdaten, Belegdaten, etc.) sicher zu stellen. Für die Erstanforderung, sofern vom Kunden nicht vorgegeben, sind maximal die letzten 14 Tage anzufordern. 
Ein in der Zukunft liegendes Anforderungsdatum ist unzulässig und wird vom Bankrechner abgelehnt. 

Für MT940, MT942, Belegdaten, CREMUL, DEBMUL und XML Kontoinformationen (CAMT Nachrichten)  ist die Wiederaufsetzreferenz dem Feld RstrtDtTm der letzten  Antwortnachricht zu entnehmen. 

Auch für ISOSTS ist die Wiederaufsetzreferenz gs. dem Feld RstrtDtTm der letzten  Antwortnachricht zu entnehmen, allerdings ist es vom BR in einer Übergangsfrist nicht zwingend zu kodieren. Wurde das Feld in der Antwortnachricht nicht kodiert, bleibt es dem Client überlassen mit welcher Information er eine neue Anforderung aufsetzt.

RestrtDtTm ist nur für die  Anforderungsarten SubTP = MT940, MT942, BELEG, CREMUL, DEBMUL, ISOSTS oder CAMTS gültig.</xs:documentation>
					</xs:annotation>
				</xs:element>
			</xs:choice>
		</xs:sequence>
	</xs:complexType>
	<xs:complexType name="ReqInfType_3">
		<xs:sequence>
			<xs:element name="BtchCtr" type="BtchCtrType">
				<xs:annotation>
					<xs:documentation>Laufende Nummer des Request mit 1 beginned anlässlich des ersten Vorkommens des BtchCtrType,  eindeutig über das gesamte Dokument, also über alle Requesttypen hinweg. Nicht notwendiger Weise lückenlos; wichtig ist die Eindeutigkeit innerhalb der MsgId zwecks späterer Referenzierung.</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:element name="Acct" type="AcctType">
				<xs:annotation>
					<xs:documentation>Acct definiert das Konto, zu dem die eKA angefortet werden.</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:choice>
				<xs:sequence>
					<xs:element name="StartDt" type="DtType">
						<xs:annotation>
							<xs:documentation>Mit StartDt wird das Buchungsdatum definiert, ab der die PDF-Kontoinformationen zu liefern sind.

Ein in der Zukunft liegendes Anforderungsdatum ist unzulässig und wird vom Bankrechner abgelehnt. </xs:documentation>
						</xs:annotation>
					</xs:element>
					<xs:element name="EndDt" type="DtType" minOccurs="0">
						<xs:annotation>
							<xs:documentation>Bezieht  sich die Anforderung auf  einen konkreten Zeitraum, definiert EndDt das Ende des gewünschten Zeitfensters.

Wird EndDt nicht kodiert, sind alle Informationen von StartDt bis zum aktuellen Tagesdatum zu liefern.  
</xs:documentation>
						</xs:annotation>
					</xs:element>
				</xs:sequence>
				<xs:sequence>
					<xs:element name="StartStmtNb" type="StmtNumType">
						<xs:annotation>
							<xs:documentation>Mit StartStmtNb wird die Auszugsnummer definiert, ab der die PDF-Kontoinformationen zu liefern sind.</xs:documentation>
						</xs:annotation>
					</xs:element>
					<xs:element name="EndStmtNb" type="StmtNumType" minOccurs="0">
						<xs:annotation>
							<xs:documentation>Mit EndStmtNb kann die Anforderung von PDF-Kontoinformationen bis zu einer bestimmten Auszugsnummer begrenzt werden. EndStmtNb muss größer oder gleich der in StartStmtNb angebenen Auszugsnummer sein, andernfalls ist mit negativen Status 708 zu reagieren.

Wird EndStmtNb nicht kodiert, so sind die angeforderten PDF-Kontoinformationen bis zu der aktuell höchsten Auszugsnummer  zu liefern.</xs:documentation>
						</xs:annotation>
					</xs:element>
				</xs:sequence>
				<xs:element name="RestrtDtTm" type="ISODateTime">
					<xs:annotation>
						<xs:documentation>Mit RestrtDtTm wird eine Wiederaufsetzreferenz für eine lückenlose Übertragung der angeforderten PDF-Kontoinformationen angegeben.
Mit IndCmpltn kann optional der Abschluss des aktuellen Auszugs ausgelöst werden.

Die Wiederaufsetzereferenz ist der Antwortmessage dem jeweiligen Attribut RestrtDtTm zu entnehmen.

Abhängig vom BR (z.B. ARZ)  kann es zu Lücken in den angelieferten eKA kommen und zwar dann, wenn die Abholung intermittierend elektronisch und am KAD erfolgt 
</xs:documentation>
					</xs:annotation>
				</xs:element>
			</xs:choice>
		</xs:sequence>
		<xs:attribute name="Doc" type="DocType" default="false">
			<xs:annotation>
				<xs:documentation>Sollen zusätzlich zu den Auszügen auch die zugehörigen Belege geliefert werden, so ist der Wert auf 'true' zu setzen.</xs:documentation>
			</xs:annotation>
		</xs:attribute>
		<xs:attribute name="Img" type="ImgType" default="false">
			<xs:annotation>
				<xs:documentation>Sollen zusätzlich zu den Auszügen auch die zugehörigen Images geliefert werden, so ist der Wert auf 'true' zu setzen.</xs:documentation>
			</xs:annotation>
		</xs:attribute>
		<xs:attribute name="Sgntr" type="SgntrType" default="false">
			<xs:annotation>
				<xs:documentation>Ist Sgntr=true so ist der PDF Auszug elektronisch 
zu signieren.

Wird von einem BR Sgntr nicht unterstützt, ist mit Status 700 zu antworten.</xs:documentation>
			</xs:annotation>
		</xs:attribute>
		<xs:attribute name="IndCmpltn" type="IndCmpType" default="false">
			<xs:annotation>
				<xs:documentation>Mit IndCmpltn wird angezeigt, ob bei erfolgreicher Lieferung der PDF Auszüge der aktuelle Kontoauszug abzuschliessen ist (true) oder nicht (false). 

IndCmpltn darf nur kodiert werden, wenn die Anforderung mittels RestrtDtTm erfolgt, andernfalls ist mit negativen Status 708 "Anforderung fehlerhaft"  zu reagieren.

Wird von einem Institut IndCmpltn nicht unterstützt, ist mit Status 700 zu antworten.</xs:documentation>
			</xs:annotation>
		</xs:attribute>
	</xs:complexType>
	<xs:simpleType name="SgntrType">
		<xs:restriction base="xs:boolean"/>
	</xs:simpleType>
	<xs:complexType name="SgntrInfType">
		<xs:sequence>
			<xs:element name="Dspsr" type="DspsrType"/>
		</xs:sequence>
	</xs:complexType>
	<xs:simpleType name="StmtNumType">
		<xs:restriction base="xs:positiveInteger">
			<xs:totalDigits value="9"/>
			<xs:pattern value="[1-2]{1,1}[0-9]{3,3}[0-9]*"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="SubTpType">
		<xs:restriction base="xs:string">
			<xs:enumeration value="alle_offen"/>
			<xs:enumeration value="hatte_Rolle"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="SubTpType_1">
		<xs:restriction base="xs:string">
			<xs:minLength value="4"/>
			<xs:maxLength value="7"/>
			<xs:enumeration value="MT940"/>
			<xs:enumeration value="MT942"/>
			<xs:enumeration value="BELEG"/>
			<xs:enumeration value="DAAB"/>
			<xs:enumeration value="DEPOT"/>
			<xs:enumeration value="CREMUL"/>
			<xs:enumeration value="DEBMUL"/>
			<xs:enumeration value="CAMT052"/>
			<xs:enumeration value="CAMT053"/>
			<xs:enumeration value="CAMT054"/>
			<xs:enumeration value="CAMT086"/>
			<xs:enumeration value="ISOSTS"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:complexType name="SWIFTAcctTp">
		<xs:sequence>
			<xs:element name="CtrCd" type="CountryCode"/>
			<xs:element name="OthrInstnId" type="Max35Text"/>
			<xs:element name="OthrAcctId" type="Max34Text">
				<xs:annotation>
					<xs:documentation>Kontonummer</xs:documentation>
				</xs:annotation>
			</xs:element>
		</xs:sequence>
	</xs:complexType>
	<xs:complexType name="TpEbzType">
		<xs:sequence>
			<xs:element name="EbzId" type="EbzIdType">
				<xs:annotation>
					<xs:documentation>Im Fall der TpEbz Message, wenn sich also die Anforderung auf (ein oder mehrere) konkrete Begleitzettel bezieht, wird hier die Identifikationsnummer des anzufordernden eBZ eingestellt. Das Element ist beliebig wiederholbar, sodass mehrere EBZ angefordert werden können.</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:element name="RestrtDtTm" type="ISODateTime" minOccurs="0">
				<xs:annotation>
					<xs:documentation>Soll  sicher gestellt werden dass nur EBZ geliefert werden, wenn sich der EBZ verändert hat,  ist in RestrtDtTm das vom BR zuletzt, anlässlich selber Anforderung  empfangene Wiederaufsetzdatum anzugeben.</xs:documentation>
				</xs:annotation>
			</xs:element>
		</xs:sequence>
	</xs:complexType>
	<xs:simpleType name="TpType">
		<xs:restriction base="xs:string">
			<xs:length value="3"/>
			<xs:enumeration value="EBZ"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="TpType_1">
		<xs:restriction base="xs:string">
			<xs:length value="3"/>
			<xs:enumeration value="IMG"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="TpType_2">
		<xs:restriction base="xs:string">
			<xs:length value="4"/>
			<xs:enumeration value="COPY"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="TpType_3">
		<xs:restriction base="xs:string">
			<xs:length value="3"/>
			<xs:enumeration value="KTO"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="TpType_4">
		<xs:restriction base="xs:string">
			<xs:length value="3"/>
			<xs:enumeration value="PDF"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:complexType name="TpVerfType">
		<xs:sequence>
			<xs:element name="Acct" type="AcctType" minOccurs="0">
				<xs:annotation>
					<xs:documentation>Acct definiert das Konto, zu dem EBZ angefortet werden. Wird kein Acct angegeben, so sind alle EBZ entsprechend der Kriterien des Attribut SubTp zu liefern.

Da das TpVerf Element beliebig wiederholbar ist, können  beliebige Kombinationen von Rollen und Kontonummern in einer Anforderungsnachricht kodiert werden.</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:element name="RestrtDtTm" type="ISODateTime" minOccurs="0">
				<xs:annotation>
					<xs:documentation>Soll  sicher gestellt werden dass nur EBZ geliefert werden, wenn sich  EBZ verändert haben,  ist in RestrtDtTm das vom BR zuletzt, anlässlich selber Anforderung  empfangene Wiederaufsetzdatum anzugeben.</xs:documentation>
				</xs:annotation>
			</xs:element>
		</xs:sequence>
		<xs:attribute name="SubTp" type="SubTpType" use="required">
			<xs:annotation>
				<xs:documentation>Im Fall der TpVerf Message, in der also die Rolle des anfordernden Verfügers die Auswahl der EBZ bestimmt, sind die folgenden Untertypen zu  unterscheiden. 
	alle_offen 	Alle EBZ mit zum anfordernden Verfüger offenen  Aufträgen sollen geliefert werden. Offen heißt, dass der gegenständliche Verfüger noch nicht gezeichnet und eine Zeichnungsberechtigung zu noch nicht vollständig gezeichneten Aufträgen und deren Auftraggeberkonto inne hat. Enthält ein EBZ Aufträge mit FF-Indikator zu nicht vollständig gezeichneten Beständen, so handelt es sich nicht um offene Aufträge im Sinne der Anfrage. D.h. der anfordernde Verfüger muss die Möglichkeit haben, durch eine von ihm ggf. getätigte zusätzliche Zeichnung den Status von zumindest einem Bestand des EBZ zu verändern. Bei den Stausindikatoren OK, VO und FF ist dies jedoch gs. nicht der Fall.
Unterstützt ein BR die Konvertierung von EBZ, sind hier auch ggf. vorhandene EBZ der V.6.0 einzubeziehen, also auf V.7.0 zu konvertieren und zu liefern.
	hatte_Rolle	Alle eBZ der letzten 28 Tage in denen der anfordernde Verfüger eine Rolle spielte sollen geliefert werden, wobei der Begriff "Rolle" weitgehend zu sehen  ist und Ersteller eines eBZ, Erst-/Zweitzeichner, sendender Verfüger umfasst. Nicht jedoch eine Mittätigkeit in nicht-relevanten Signaturen; diese EBZ sind hier nicht zu liefern!
Die Verfügernummer des anfordernden Verfügers ist der XML-DSig zu entnehmen</xs:documentation>
			</xs:annotation>
		</xs:attribute>
	</xs:complexType>
</xs:schema>
