Organization: Financial Services Technology Consortium

Date: March 29, 1999

Digital Signatures For Financial Services

The Need for Digital Services in Financial Services

The contracts, financial instruments, and negotiable instruments used today by financial institutions are writings on paper which are authenticated by handwritten signatures. Electronic documents, authenticated by cryptographic digital signatures, can have the same properties of integrity, authenticity of origin, and non-repudiation as paper documents, and they can be used as direct replacements for the paper documents.

However, to replace paper documents signed electronic documents must be able to be processed like paper documents in multi-party work flows. A work flow node must be able to:

As concrete examples of these functions, a payee must be able to remove attached remittance advices from an electronic check before endorsing and depositing it. A payee must also be able to combine endorsed electronic checks from multiple payers and create a single deposit to his bank.

While the FSTC's experience and existing trials relate to financial instruments, these capabilities are important to the use of XML for secured work flow documents in general applications.


The FSTC has provided a proposal "Signed Document Markup Language" to W3C. This proposal was based on the non application-specific sections of the "Financial Services Markup Language" developed by the Electronic Check Project.

Since then, the whole of FSML has been published. "Financial Services Markup Language (FSML) Version 1.17" is available for download at along with an "Architectural Overview" at . The sections 2-5, "Notation", "Document Formatting Rules", "Generic FSML" and "Combining Documents", describe the fundamentals of FSML, including signatures and certificates. The remainder of the document is the specifics of the use of FSML for Electronic Checks. For the current draft of FSML Version 1.5, please contact

FSML was based on SGML and differs from well-formed XML principally by omitting end tags on leaf elements and by using un-ordered lists. FSML 2.0 will be based on XML and will expand the types of information carried in FSML documents. However, based on our experience with FSML implementations, the currently defined structure of the digital signatures satisfies the business requirements for signing structured information in financial instruments.

Electronic checks in FSML are being used in a US Treasury Market Trial to pay suppliers to the Department of Defense. The electronic checks are drawn by the US Treasury Financial Management Service on a US Treasury account at the Federal Reserve Bank of Boston. They are emailed to suppliers who process the payments, and detach, endorse and deposit the electronic checks by email to their accounts at Bank of America and BankBoston. Checks of up to $100,000 each have been processed and cleared between Bank of America, BankBoston and the Federal Reserve Bank of Boston. The trial implementation followed security analyses and studies to satisfy banking and government auditors and regulators that payments over the Internet could be made safely using FSML signed electronic documents.

Bank servers which process FSML and verify signatures have been developed by IBM and Sun. Electronic check writing, endorsing and depositing applications have been developed by RDM Corporation for use with electronic checkbook smart cards from Information Resource Engineering (IRE). The public key infrastructure and card initialization and issuance processes have been implemented by GTE Internetworking and IRE.

Expansion of the trial, additional trials and standard commercial operations are planned for 1999, both domestically and internationally.

Expectations for the Digital Signature Workshop

We expect and desire that the Workshop will result in a charter for a W3C Digital Signature Working Group which will standardize:

The Working Group should also study and recommend how:

Following are design objectives for FSML signatures which the Working Group should consider in its development of requirements for digital signatures.

Design Objectives for FSML Signatures

Cryptographically Signed Financial Instrument -- FSML signatures were designed to allow the use of cryptographically signed electronic documents in place of paper financial instruments. The only exceptions are bearer instruments, which are not allowed due to the ability to make perfect copies of digital instruments. Otherwise, all signature operations commonly found on paper documents were intended to be supported.

Detaching of Parts of Signed Documents -- In the flow of financial documents, parts of the document may be removed by one of the parties to the flow. For example, the payee may remove an invoice attached to the payment. The FSML signatures are created by signing the hash of a set of hashes on individual blocks of information in the FSML documents. This supports removal of individual blocks without invalidating the signature with respect to the remaining blocks.

Combining of Signed Documents -- In a flow of financial documents, multiple documents individually signed by previous parties may be combined into a single document and sent on to one or more subsequent parties. An example is a deposit document, which includes multiple endorsed checks, deposit slip information, and the depositor's signatures. The FSML document structure provides for enveloping FSML documents within other FSML documents, and the name references are disambiguated with respect to the document structure.

Compatibility with Smart Card Processing -- FSML documents and the signature blocks have relatively simple structures. This allows FSML document parts to be passed to smart cards, with the hashing and signing taking place within the smart card. Hashing and creation of the signature block on the card enable the use of card-produced nonces during hashing and the insertion of user information secured by the card

Nonce to Strengthen Hashing -- One class of attacks on hash algorithms is to create two messages M1 and M2 which both hash to the same value H, dupe the victim into signing M1, and later substitute M2. The successful attack on MD4 by Hans Dobbertin was of this type. FSML specifies that the smart card compute a random nonce, prefix it to the blocks before hashing, and include the nonce in the part of the signature block that is hashed and signed. Since no one outside of the smart card can control the message being hashed, the type of attack described above is defeated.

User Information in Signature -- FSML signatures provide for the insertion of user identity information into the signature block by the smart card. The smart card allows the signer to choose which information is inserted (e.g. telephone number, drivers license, social security number) but the signer has no control of the values. The specific values are written into the card by the card issuer at initialization time. This provides a reasonable degree of assurance to recipients, such as merchants or check guarantee services, that the information is valid (up to the tamper-resistance of the smart cards), while providing signers with control of which information is disclosed with each signature in order to address signer's privacy concerns.

Signature Types -- FSML signatures include a signature type to identify a signature as one of the following types: check, endorsement, deposit, co-sign, counter-sign, co-endorse, counter-endorse, log-signature, bank account, certification, endorse to third party and generic. Signers are restricted to being able to make only specific types of signatures by parameters in information signed by the bank. Thus, one signer (e.g. a treasurer) may be able to make the original signature on checks while another signer (e.g. another officer of the corporation) may be restricted to only co-signing the checks. This allows finer control over key usage than the restrictions currently provided in standard X.509 Version 3 certificate extensions.

Logging to Provide Receipts -- FSML includes specific elements in the check and endorsement blocks which are logged in the smart card in order to satisfy Regulation E requirements for provision of receipts of a transactions.

Canonicalization and Hashing Rules -- FSML specifies the character repertoire, line lengths, white space treatment, allowed white space within tags, processing of character entities, and other rules related to hashing of the FSML blocks. Some of these issues will not apply to XML in general, but they must be specified in detail in order to ensure reliable signatures. It would be prefered to have a single canonicalized format which can be computed efficiently by smart cards using the external representation, by browsers from the document object model, and by high-volume servers using special-purpose parser/verifiers.

FSML Signatures

The FSML signature block has the following structure:


signature block start tag


character string "cccc" contains the name of the signature block in case it is referred to by another signature block, i.e. it is counter-signed.


if true, then the application must understand all contents of the block


version number of the signature block. Note: all blocks have blkname, crit, and vers.


start tag of signature block contents which are hashed and signed by the signature

<blockref req="false">cccc

"cccc" names a block that is hashed and signed. If the attribute req is false, then the signer is asserting that the block can be removed without invalidating the signature.

<hash alg="sha">6666

base64 encoded value of hash on the block just named

blockref and hash repeat in pairs for all blocks hashed and signed


random character string generated inside the signing hardware that is prefixed to each block before it is hashed


"cccc" names a block containing a certificate or a reference to a certificate that can be used to validate the signature


defines the business role of the signature, as defined above



distinguished name and serial number that reference a certificate which can be used to validate the signature.


names the algorithms used to hash and sign the contents of sigdata


date and time that the signature was made


identifies the place that the signature was made


names the signer


the address of the signer


the phone number of the signer


the email address of the signer


an identification number such as drivers license or social security number


another identification number


the end of data hashed and signed by the signature


the result of hashing and signing sigdata using the algorithm


signature block end tag

Structure of FSML Documents

An FSML documents begins with an fsml-doc start tag which has the docname and type attributes. Type plays a role similar to referencing a DTD. An FSML document can contain FSML documents and/or FSML blocks, where a block is an element that has the standard first elements of blkname, crit, and vers. Since both the blkname value contained in the hashed block, and the blockref value in the sigdata scope of the signature block are hashed and signed, the values cannot be changed. Thus, if the same blockref value occurs in two signed documents being combined into a third document, there will be a name collision.

FSML avoids this name collision by assuming that a signature block contained in a document refers to signed blocks within the same document. Application of a subsequent signature is done by wrapping the two or more documents to be signed in an outer FSML document and placing the new signature block in the outer document. The new signature in the outer document may sign blocks in inner documents by referring to them by a dotted concatenation of docname and blkname values.

Public Key Infrastructure

The FSML certificate block has the following structure:


start tag of a certificate block


name of the certificate block in case it is signed


if true, then the application must understand all contents of the block


version number of the certificate block


may also be x509v1



distinguished name and serial number that reference a certificate which can be used to validate the signature


base64 encoding of the certificate


end tag of a certificate block

As described above, the signature block can reference a certificate block by the blkname of the certificate block, or it can reference the certificate issuer and serial number. Therefore, both are carried in FSML syntax in the cert block, so that the application can easily recognize which block carries the certificate without decoding and parsing the certificate itself. The certificate references also allow certificates to be passed by reference, instead of by value, and the mechanism is able to support PKI approaches which do not use certificates, but rely on storage of public keys in association with customer account databases.


The FSTC is sharing its prior experience and current design with the W3C because we believe that a common approach to signed XML can be applied to a wide range of signed XML documents and forms. This is a fundamental security infrastructure component which can greatly encourage and assist the movement of business communications and financial information from paper to electronic form. Once it is available, the implementation of specific applications is largely a matter of establishing standards for the content of business documents, much of which can be based on business practice, law and regulation already established for paper documents.

Milton M. Anderson

FSTC Advisory Committee Representative to W3C