FpML Issues Tracker

Rule 19 states: “Each party/account/accountId must be unique. An account is identified by party/account/accountId or by party/account/accountName”

Account is no longer a child of Party at FpML 5-x (see group “PartiesAndAccounts.model”), therefore the 4-x expression of the rule is no longer applicable.

Also, the assertion that an “account is identified by … party/account/accountName” is dubious. The account is identified by the mandatory accountId (the clue is in the element name); accountName is optional and may be supplied for reference purposes.

I think the rule can be simply updated as follows:

Rule: Each account/accountId must be unique. Each account/accountName must be unique.

Comment: Both an account’s name and account Id must be unique. The accountIdScheme is part of the partyId uniqueness check.

The schema allows content as follows:

123
Name ABC
456
Name DEF
789
Name GHI

We sent an email to the coord-WG to verify is multiple names are really necessary.

In either I don’t think that the schema structure should change.

Consider the following:

123
Name ABC


456
Name DEF


789
Name GHI

Adding a container element is generally considered good practice. In this case I think that 1) it breaks compatibility.

A consumer can access a specific account name like this:

//account/accountName[@accountNameId=’account_name_scheme1′]

… and with a container element like this:

//account/accountIdandName/accountName[@accountNameId=’account_name_scheme1′]

Fixed as agreed. (Removed the party from the xpath leading to the account)

The Coordination Committe discussed 6/18 a solution that may break backward compatibility. Marc will develop a proposal for review by the Standards Committee. The change would be implemented in 5.4.

implemented. removed any reference to account name.

all done.