The OECD Standard Transmission Format Version 2.1
for international information exchange in taxation
Where does STF fit in? 3
What content does STF support? 3
What is the main structure of an STF message? 3
What is the modular structure of the schemas for STF definition? 5
What is the structure of an STF_DIRECT document? 6
Where is detailed advice for all of the elements and their content to be found? 16
How is coexistence between SMF and STF supported? 17
- Bridging from SMF to STF 17
- Bridging from STF to SMF 19
Examples of Elements and Messages 19
What artefacts are available for STF? 25
1. Where does STF fit in?
1.1 STF, the OECD Standard Transmission Format, was released in 2004. STF has been designed as the successor of SMF, the OECD Standard Magnetic Format for international information exchange in direct taxation, which was first adopted in 1992 and re-formulated in 1997. There is currently no set time limit for the co-existence of the SMF with the STF, however, it is expected that over the next few years countries will increasingly adopt XML-based standards, and at some point in time the SMF will therefore become unnecessary and support will consequently be discontinued.
1.2 STF defines the format of message content for international automatic information exchange on tax matters. This is achieved through an Extensible Markup Language (XML) schema. STF does not define the way messages are transmitted, encrypted etc.
1.3 Whilst an important initial design objective for STF was to stay as close as possible to SMF (thus making bridging using the bridging programs provided by the OECD possible), it is also a goal to support countries adopting and migrating to the widely accepted standard of XML to simplify and improve the effectiveness of automatic exchange of information, through improved features which XML provides, such as automatic validation of files and consequent identification of errors.
2. What content is STF designed to support?
2.1 SMF was constructed to support automatic information exchange (in the sense of Article 26 of the OECD Model Convention) for direct tax purposes. Being primarily – even if not only - a modern version of SMF, STF is also designed for the automatic exchange of information relating to Article 26 of the OECD Model Convention. The first message format built with STF has been STF_DIRECT for exactly this sort of information.
2.2 It was, however, also a design objective for STF to be flexible and extensible (hence the use of XML), therefore STF can easily be extended for any other kind of tax information messages, including both the use for other than automatic exchange, and also for other content than the conventional income information of the SMF type.
3. What is the main structure of an STF message?
3.1 As usual for messages, STF messages are hierarchically structured with a header (MessageSpec) specifying technical information for the message as a whole and a variable number of detail documents. (In this context the word “document” is used in a general sense, not in the strict meaning of XML where a document is always the most comprehensive unit that contains one and only one root element. Documents in the strict XML sense are referred to as messages here.) Currently there is only one kind of such documents defined (STF_DIRECT), but as other document formats are developed, they can be included in such messages as well.
Figure 1 depicts this overall structure.
Figure 1: Overall Structure of STF Messages
In XML schema terms this is expressed as
An attribute of name “version” and value “2.0” designates the current status of development.
3.2 The structure of the message specification (header) element is shown in figure 2.
Figure 2: Structure of the Message Specification Header
The element contains data identifying and describing the message as a whole.
'SendingCountry' and 'ReceivingCountry' are to identify the relation of the transmission, so this is visible at the very top of the message and independent of the transmission content further downstream. These elements are optional because they are not necessary for successful transmission (note that there are no exactly corresponding fields in the SMF record). It is however, strongly recommended to use these identifying fields as intended.
‘Warning' is for legal constraints: free text expressing the restrictions for use of the information this message contains and the legal framework under which it is exchanged.
'Contact' should contain all necessary contact information about persons responsible for and involved in the processing of the data transmitted in this message, both legally (competent authority) and technically. This is free text as it is not intended for automatic processing.
'MessageRefId' is a unique identifier that the sender has to attribute to this message and shall be used in any correspondence.
'TaxYearList' is a list of all tax years for which information is transmitted in the documents of the current message. To indicate a tax year, the date of the last day of that year is given. Format for dates is ccyy-mm-dd. List items have to be separated by blanks.
4. What is the modular structure of the schemas for STF definition?
4.1 STF documents are XML documents. The TIES Technology Task Team has defined:
(1) an XML schema document (stftypes-2.1.xsd) containing a set of simple and complex data types for the use in any STF schema defining a particular document type
(2) an XML schema document (stfdirect-2.1.xsd) for the definition of the XML documents that will replace SMF records, together with the definition of the message container STF_OECD for these documents
(3) two additional XML schema documents for OECD and ISO code lists to be used in STF documents, these schemas containing the admissible code-values.
4.2 The core of STF is the definition of the data types to be used in STF documents. It is expected that this set of data types will be extended as new documents are defined. With the advent of new document definitions, additional needs are likely to arise that have not yet been addressed by stfdirect. Such new types are expected to fall into three categories:
(1) types that – even if not necessary for stfdirect – are of a certain generality and shall therefore be added to the stftypes collection
(2) types that are specially needed for just a certain document definition without a more general application; they shall be added in a separate XML schema for the use of that one document definition only
(3) types that though close to others already defined in stftypes differ somewhat for the modelling of some aspect in the new document; they shall be derived as extensions or restrictions of their general stftypes relatives.
4.3 As long as stfdirect is the only document type in the STF family, it is considered desirable not to complicate the schema structure more than needed for this situation, therefore:
(1) the general message structure and the stfdirect document structure are defined inside the same schema;
(2) all the above mentioned schemas are put into the same namespace (urn:oecd:ties:stf:v2.1);
This results in the structure shown in figure 3.
Figure 3: Inclusion Structure of STF schemas (to date)
4.4 When new document types are added in the future, the structure of figure 3 will probably not be adequate any more. Every document type will then be defined in a separate namespace together with its special data types and the general STF (core) types including the type for the message will be imported.
5. What is the structure of an STF_DIRECT document?
5.1 The high-level structure of an STF_DIRECT document is shown in figure 4.
Figure 4: STF_DIRECT, highest level
It will be noted that the components of this structure fall into four categories:
DocSpec, PaymentData and OtherInfoeach represent a particular type of information occurring once in the document.
All other components are of the same category: they denote parties in the transaction reported.
The construction may at first seem complicated, but should become clear after inspection. A dotted line box indicates “optional”, data for parties so denotated can either be present or not, whereas boxes with solid lines indicate obligatory entries. In a document of stfdirect type, data for the beneficial owner must be present, whereas data for an agent or intermediary acting on behalf of the beneficial owner need not be present. The modelling of the data for the payer side is more sophisticated. Data for at least one of “actual payer” and “payer agent or intermediary” are provided, but there is no stringent rule that a particular one of those is obligatory. The “choice” symbol stands for “one of these”. You may want to verify that the construction given in Figure 4 allows for all of these situations:
actual payer data only
payer agent or intermediary data only
both actual payer and payer agent or intermediary data
and at the same time requires one of these situations .
The DocSpec element serves as a descriptor of the particular stfdirect document to which it belongs, just as the MessageSpec element does for the whole collection of documents in the message. DocSpec has this structure:
Figure 5: Document Specification Element
The document type indicator (DocTypeIndic) contains administrative data about the status of the document (is it “new” data sent for the first time – the normal case, hopefully near to 100% of documents -, or is it a correction of a document sent before, or is it a repetition of a document which was sent before but possibly not received in an orderly way).
The document reference identification (DocRefId) is the unique identifier of this document. For later reference to be possible it has to be unique at least within the message in which it is contained.
The following two elements (CorrMessageRefId and CorrDocRefId) are optional and only needed in case of a correction or a repetitive sending, however obviously in the case of a message or document being corrected they will be necessary to identify the message or document being corrected. The elements refer to documents sent before by giving the DocRefId and MessageRefId of the document referred to and the message it was in.
Payment data are the reason why the document is sent. Here the sending administration enters the information that has become known about income of the beneficial owner in the source country. Here is the structure of the element:
Figure 6: Data about the Income
Each single document serves for information about one and only one income item of the beneficial owner. It follows that several documents have to be transmitted (preferably in the same message) if there is the need to inform about income from several sources, at several points of time etc.
The tax year to which the payment belongs is entered in the element TaxYearEnd, which is a date field (format ccyy-mm-dd in coherence with general XML rules). This is not just a four digit element for the year in order to cope with cases where the tax year does not coincide with the calendar year.
The element SMFTaxYearEnd has been added to be able to convert from SMF to STF in the case the exact date is not present within SMF. Dates can be present in one of the following formats:
It is advised not to use this element when sending out STF.
The type of the payment received by the beneficiary is coded in the elements OECDPaymentType and SpecificPaymentType. Their structure is governed by these schema definitions:
The OECD code describing the nature of the payments:
06 Income from immovable property
21 Other income
Type for explanation of a payment by a code that is specific for a certain legislation, e.g. for the sending country. In the OECD file for this schema part is a dummy code. The enumeration element and the annotation-documentation in the OECD prepared file serve as an example for real legislation specific codes and their documentation.
In order to provide sufficient freedom for describing the nature of the income a country/legislation specific payment code may be included in addition to the standard OECD payment code. A sending country may want to transmit a special income code used in this country to best describe what income the beneficiary has received.
If no such specific code is transmitted, the element SpecificPaymentType should not be used. If it is used nevertheless, it has to look exactly like this in order to keep the document from becoming invalid:
A sending country that wants to use specific payment codes has to edit the file specifictypes_v2.xsd. This file keeps the (country) specific codes (by now just for payment types) separate from the general OECD types. The attribute specificPaymentTypeQlf, which has to be fixed for all documents sent by this country and relying on this particular set of payment codes, has to be set to a value identifying this code list (e.g. country code + year). Then the values of the codes in specifictypes_v2.xsd has to be adjusted according to need and should be accompanied by proper explanation of the meaning of the codes.
For the payment itself there are a number of elements. It has to be born in mind that each of these elements belong to one and only one income item; they represent different aspects of this income item, such as the gross payment, the net payment, the tax, and the refund. Here is what the element has to look like in XML schema format:
The SMFPaymentDate element should ONLY be used in a STF document created by the transformation of SMF into STF (e.g. by the bridging tool).
A new STF file created MUST use the PaymentDate element.
The payment date can be expressed in a date format or as an SMFDate_Type, allowing an incomplete date.
The payment qualifier (paymentQlf) is the attribute which distinguishes gross, net etc. and has to be one of gip (gross income paid), nip (net income paid), twh (tax withheld), and trf (tax refunded).
The tax rate (TaxRate) can optionally be given for any payment item. Tax rates have to be entered as decimal numbers with a total of four digits, two before and two after the decimal point.
The date of the payment can be added to any of the items and should designate the day specific to the particular payment, e.g. the refund.
Monetary amounts in STF are always qualified by an attribute currCode which is to give the ISO 4217 currency code relevant for the number in the MonAmnt element.
For cases where the account into which the payment went matters (and is known) there is a field AcctInfo available, which looks like this:
The IBAN, ISIN, and SWIFT elements shall contain account identifiers as their names say and shall have the standard format of the respective identifiers. OBAN and OSIN stand for “other bank account number” and “other securities identification number” and are to be used for non-standard cases; attributes 'acctNoQlf' and ‘secNoQlf’ respectively have to be used to indicate the kind of such numbers.
Other information that may be needed to adequately describe the case at hand isn’t part of the element PaymentData but goes into the element OtherInfo. There are no restrictions to the format of this element, which may also have child elements. The sender has to make sure both by using adequate tag names and adding explanations that the receiver is able to understand the sender's intention. As the document is possibly processed automatically there is no guarantee when or even that the content will be recognized by the receiver.
Identification of the parties involved in the payment is vital for the document to be of any value at all. Therefore a large part of the document content is given to data describing the parties. This is done in a uniform way for all parties, in XML language: all party elements like RecipientBeneficialOwner, ActualPayer etc. are of the same type, Party_Type. It is therefore essential to understand Party_Type. Here is the broad picture:
Figure 7: Common structure of all Party elements
There has to be at least one name and one address element inside a party element, but to offer a wider range of descriptive information the number of such elements is not limited. That means that you can add nicknames, names at birth etc. as well as business and other addresses. The nature of names and addresses can be indicated by optional attributes, the admissible values are:-
and for addresses:
Most of this will be self-explanatory, however note that aka stands for “also known as”, and dba for “doing business as”. SMFAliasOrOther is an attribute value that should only be used if the document is generated by a bridging program from a SMF record. If there is an entry in the field group “alias or other” in the SMF record (a group within the beneficial owner group which holds all of “aka”, “dba” etc.), the bridging program will not be able to decide which kind of name that is and therefore will translate just into “SMFAliasOrOther”.
The detailed structure of names and addresses is explained in more detail later.
The residence country (in the relevant time period), to be represented in element ResCountryCode by its ISO 3166 two-byte alpha code, is considered to be a property of the party, not an address, although it is most likely that it will coincide with at least one of the address country codes for this party. To be sufficiently general, the element had to be left optional, however please be aware that information about an individuals’ residence country will probably be essential for successful matching of the record.
Another important item of the party description is formal identifiers (to be entered in elements PartyId), for which 3 optional entries are provided. The idea is to give whatever official identification “numbers” are known by the sending country. PartyId elements are declared as shown in Schema Fragment 5:
The attribute partyIdType is to distinguish between the kinds of identifiers like Tax Identification Number (TIN), Tax File Number (TFN) and others. To-date TIN, TFN and IdNo are defined as valid entries. It is required to add another attribute (issuedBy) to describe the body that has issued the identifier to the party. In the case of a TIN this should be just the country code of the issuing country, in other cases a non-formalised entry will be adequate.
To even better describe and hopefully identify the party, an optional element PersData can take more information, depending on the type of the party (individual or legal). The content will become clear from Figure 8:
Figure 8: Additional identifying data about a party
The date of birth can be present in a Date format or as an SMFDate_Type type allowing incomplete dates.
In the following paragraphs we will explain how names and addresses are dealt with inside the party structure of STF.
Here is the broad picture:
Figure 9: Name structure
It will be noticed that a name can be either a NameFree element, or a NameFix element, or a sequence of both. NameFree will be used to deal with the common situation that it is not clear for the sending country what are the roles of different particles in a sequence of words that constitute the name of a party. In such cases it may be better to leave it to the receiving country to sort that out, as it may be better acquainted with the name structure of the party. Ideally of course the name of the party is well structured into parts that are identified by the sending country. To serve cases where a structured name (NameFix) can be given, but only with some doubt as to the validity of the break-down into its parts, the sending side may choose to provide a NameFree in addition.
Widely accepted international standards for name structure are only just emerging and for individuals STF has chosen to generally adhere to the CIQ standard for names (CIQ: Customer Information Quality, an OASIS family of standards), resulting in the following structure:
Figure 9: Structured Name in STF
All elements in this structure are optional, as there is no guarantee that a particular one will definitely be present in all cases. Of course there will have to be at least one entry for the name to be useful. Following CIQ, FirstName, MiddleName, NamePrefix, and LastName designate exactly what their names say, that is: the sequence in “normal” usage. The meaning e.g. of the first part of a name may, however, vary from one cultural environment to another. Therefore all of the elements mentioned have to be qualified by an attribute, which is called xnlNameType (xNL is the standard for names in the CIQ family of standards). For the time being there is no predefined set of values for xnlNameType, as CIQ also leaves this to the user. “given Name”, “family name” etc. may be values you may want to use.
For legal entities always the free form shall be used for the name; there does not seem to be any useful standardised way of breaking down such names into well-defined parts.
The top level view on addresses is this:
Figure 10: Address structure
Like for names the address can be either an AddressFree element, or an AddressFix element, or a sequence of both. The country code is left outside these structures, as it is be a well-discernable field that never should be imbedded (and hidden) in an unformatted character sequence like in AddressFree.
For addresses more or less the same remarks apply as for names: AddressFree will be used to deal with the common situation that it is not really clear for the sending country what are the roles of different particles in a sequence of words that constitute the address. Also in such cases it may be better to leave it to the receiving country to sort that out, as it may be better acquainted with the address structure of the party. Ideally of course the address of the party is well structured into parts that are identified by the sending country. To serve cases where a structured address (AddressFix) can be given, but only with some doubt as to the validity of the break-down into its parts, the sending side may choose to provide a AddressFree in addition.
Widely accepted international standards for address structure are only just emerging. For STF it has been considered to mimic the CIQ standard for addresses as it did with names. It was found, however, that xAL, the address standard inside CIQ, has gained its extreme flexibility and wide applicability by a degree of complexity that did not seem adequate for STF. This design decision was flagged as “to be monitored”, as possible widespread use of xAL in OECD member countries may well suggest reconsidering the design. For the time being, addresses in their fixed format are structured like this in STF:
Figure 11: Structured Address in STF
The only mandatory element in this structure is the name of the city. Other address parts shall be given as available.