The BSB standard defines an electronic statement that can be sent by a Financial Institution to its wholesale customers (e.g., corporations, governments, institutions) detailing their usage of financial services and their related charges. A BSB statement includes volumes and associated charges for all billable services rendered during a billing cycle, usually one month.

This standard has been developed by TWIST at the request of a corporate interest group, led by General Electric.

BSB has been created to help corporations:

• enhance control over the cost of banking services,
• automate account reconciliation and account for bank fees and
• simplify the task of complying with market regulations such as Sarbanes Oxley

From the perspective of the Financial Institution, BSB represents a new information product which helps differentiate bank transaction services.

A TWIST BSB statement is designed to report on all bank services rendered during the reporting period. A BSB statement includes:

• For one or more accounts in a client/bank relationship
• For a defined period in time (typically the most recently concluded bank billing cycye)
• Identification of all chargeable services used in the period
• The volume of those services during the period
• The per item and total charge for those services
• Select balance and interest information.
• Relevant tax information.
• How the Bank and Tax Authorities have been compensated for these charges and tax items.

BSB has been designed to be used in any and all countries including Australia, Denmark, France, Germany, Singapore, United Kingdom, United States of America

Conceptually, BSB is the global equivalent to the ANSI 822. Essentially a superset of the 822, BSB includes virtually all of the substantive business requirements and capabilities found in the 822. .BSB accommodates multi-currency and value added tax., features not found in 822.

BSB is a control tool. It has been devised to complement existing activities, such as invoicing and account reconciliation, not to replace them.

Banking side software suppliers include: Weiland Financial Group, TriSyn Group

Corporate side software suppliers include: Weiland Financial Group, Chesapeake Systems

Currently known to be live: Danske Bank,

In development or live: Barclays, Citigroup, Deutsche Bank, HSBC, KBC, Westpac

The file “0505TWIST_GEBSBRequirements_V0_21_Baseline.doc” describes in great detail the specification of a TWIST BSB standard message. It can be downloaded from the following URL on the TWIST website:
http://bsbstandard.twiststandards.org

A BSB message is composed by the “header” section and multiple “electronicStatement” sections.

The “header” is a TWIST messaging standard section common to all TWIST messages. It contains static data regarding the Sender, the Receiver and elements identifying the message as part of a specific “communication”.

Each “electronicStatement” section represents a statement and contains the data relative to the BSB divided into customer accounts.

A statement is structured in two sections: “statementHeader” and “statement”.

The “statementHeader” contains static data regarding both the Financial Institution sending the statement and its account holder.

The “statement” contains elements pertinent to the FI customer (the “account” section) and, finally, the banking services billing data structured in a number of aptly named sections.

A BSB message supports multiple statements as well as multiple accounts. In fact a statement can be articulated in a hierarchy of parent and child accounts all identified by codes, to reflect most organisational requirements.

In a BSB communication only the TWIST BSB message is provided as a standard document. In fact the purpose of a BSB communication is fulfilled when the BSB message is delivered from the originator to a recipient. How the message is sent and received, frequency, method of transmission (push/pull), and security are all out of the standard’s scope and are agreed between the sender and the receiver.

The “Header” section must specify a type and code for the party sending the electronic message (normally a Financial Institution).

In addition, for each statement contained in the message, the “statementHeader” section will specify a sender by type and account number. The content of all the elements should be agreed between the sender and the receiver.

In the “Header” section can be specified a type and code for the party receiving the message.

Despite that, for each statement in the “statementHeader” section a message recipient is also specified by an account number. The content of such elements is agreed between the sender and the receiver.

It is critical that every statement in every BSB be uniquely identified as to domicile bank, account number and statement date. These are the elements used within receiving systems to form the unique database key. The receiver (customer) will always want to uniquely identify a statement based on the bank in which the account resides, the account or relationship number used to identify the account and the statement date.

Yes. The BSB electronic message originator is specified in the “Header” section, while the Financial Institution that sends the data it contains can be specified in the “statementHeader” section.

If you have no specific value to send in an optional element, then do not include the element. Do not send the optional element with a filler value such as “string” or “str”.

If you do not have a particular value to send in a balance, price, charge or total element then do not include the element. In particular mode, do not send a zero value as the receiving system will interpret a zero value as an actual, specific value of zero, while it will interpret a “null” value (missing element) as something for which the sender did not have a specific value.

It is strongly recommended that all the statements contained in the TWIST BSB message cover a single calendar month period. This provides a common time period and cycle to be used in variance and trend reporting and in summarizing results across the receiver’s multiple banks.

In constructing the BSB standard, TWIST has worked with many different banks and organisations to encompass all possible business requirements. Despite on one hand this allows implementation across the international market, it also means that there will be a number of elements in the XML standard that may only be implemented in certain organisations or geographical locations.

The business data sections are held in the “statements” section of the BSB message and are as follows:

1. Account Section
   Identifies the account or relationship whose statement information follows.
2. Tax Explanation Sections
   One or more sections which provide word definitions/explanations of various tax reason codes used within the statement.
3. Rate Sections
   One or more sections that carry the non tax, per annum rates values used by the account during the month such as the earnings credit rate, or the overdraft interest rates. This section does not carry any tax rates.
4. Currency Translation Sections
   One or more sections that allow the receiver to translate the various currencies contained within the statement, one to the other.
5. Balance Sections
   One or more sections that carry the value of various balance held within the account during the month.
6. Compensation Sections
   One or more sections that carry the summary value of charges and taxes that occurred during the month.
7. Service Sections
   One or more sections that recount all chargeable events that occurred for this account during the reporting cycle, typically a calendar month.
8. Tax Sections
   One section which summarizes the taxable activities of the account or relationship during the month. There may be multiple Tax Regions reported in a Tax Section if the relationship parent account contains multiple Tax Regions.
9. Balance/Float Adjustment Sections
   One or more sections that identify balance or float adjustments to the account.
10. Service Adjustment Sections
    One or more sections that identify line item service adjustments to the account. They reflect adjustments to statements from prior reporting periods.

The user is referred to the following sample XML document files available from the TWIST web site at the URL http://bsbstandard.twiststandards.org:

• TWIST3.1Billing.ElectronicBillingMsgOnlyMandatoryElements.xml
• TWIST3.1Billing.ElectronicBillingMsgInclOptionalElements.xml

Although the “balance”, “compensation” and “taxDetails” sections are not required by the BSB schema, they are none the less critical. Some of their specific totals should still appear as the receiving system can’t be asked to guess and derive its own totals of charges and taxes due.

Required totals are described in the file “0505TWIST_GEBSBRequirements_V0_21_Baseline.doc” that can be downloaded from the following URL: http://bsbstandard.twiststandards.org

A BSB standard message makes two provisions to identify each line item in a statement. The first one is required and identifies a particular service with an ID code internal to the FI. The second one is an optional element ready to accept a code from a set of industry recognised codes.

The actual code element is “service/commonCode” . A number of different code series may be used to identify service ffess including bank proprietary servie codes as well as the service codes published by the Associiation for Financiae Prfessionals (AFP).

Note that the AFP Service Code set is proprietary and available from AFP for a fee. A one time charge allows the bank or FI unlimited use of the codes in any and all customer 822 and/or BSB files. The AFP Service Codes are available from the AFP. Phone +01-301-907-2862, Web: http://www.afponline.org/pub/store/pubs/tma822.html

Furthermore, as AFP is more relevant to the US market, presently the TWIST team is working to extend the code set to further develop BSB as a across banking reporting standard.

The services within a statement are identified by both “bankServiceID” and the “subServiceCode” elements. Thus “bankServiceID” can have duplicates as long as, for those same duplicate elements, different “subServiceCode” values are specified.

It has to be noted that, it should not be assumed that the “serviceDescription” elements are used by the receiving system to differentiate services must not be made.

Yes. In a BSB statement can be specified account specific currencies, a banking services billing settlement currency, a tax payment currency and their conversion rates.

The BSB standard has been designed with the assumption that all bank service fees are quoted exclusive of tax. Thus BSB makes the appropriate calculation depending on the way the service is quoted (including or excluding tax) and the applying tax rate.

Taxes can be presented in a per-service line by line detail or grouped totals. Settlement currency translation can also be displayed.

In a BSB statement each account is assigned to a tax region. For each region services can be taxed differently, thus the capability to apply multiple rates (e.g. National VAT, Local VAT, per transaction fee) or no rate at all. BSB also supports a hierarchy of multiple accounts residing in different tax regions.

Service fees totals are displayed in the “Compensation” section, while average account balances are to be found in the “Balances” section. Definitions of the available optional and mandatory balances and totals is available on the specification file to be found on the TWIST web site: http://bsbstandard.twiststandards.org