[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: FpML-MWG40 More on accounts and account references



I'm not sure about your solution, Marc.   The "account" is related to
settlement or clearing, not really to the accountant.  In my example, the
accountant is probably Citco, which we didn't even bother to model.  If
anything, the accounts probably relate more to other roles in the trade
side structure.

 

Also, I am not too keen on the nested referencing structure you describe
below.  If we do want to group the party and account references, we could
do something like this:

 

<tradeSide>

            ...

            <settlement>

                        <settler href="abcBank"/>

                        <settlementAccount href = "bankAccount"/>

            </settlement

            ...

</tradeSide>

 

 

Brian Lynn, CTO

Global Electronic Markets,  <http://global-emarkets.com>
http://global-emarkets.com

High-speed FpML matching, reconciliation, and validation:

 <http://fpml-mediator.com> http://fpml-mediator.com

 

  _____  

From: Marc Gratacos [mailto:MGratacos@xxxxxxxx] 
Sent: Wednesday, February 02, 2005 11:09 PM
To: mwg@xxxxxxxxxxxxxxxxxxxxxx
Subject: RE: FpML-MWG40 More on accounts and account references

 

Thanks Brian. I understand now :)

 

As you said, one option may be to do the link through the tradeSide
structure having a new account reference within the accountant:

 

<tradeSide id="FGFRoles">

...

  <accountant href="MORGCAB">

    <account href="ACC0"/>

  </accountant>
...

</tradeSide>

 

But maybe there are better solutions.

 

Thanks again,

-Marc

 

  _____  

From: Brian Lynn [mailto:brian.lynn@xxxxxxxxxxxxxxxxxxx]
Sent: Wed 2/2/2005 6:52 PM
To: mwg@xxxxxxxxxxxxxxxxxxxxxx
Subject: RE: FpML-MWG40 More on accounts and account references

Marc -

 

Yes, this is exactly what I've done. 

 

But how do we know which account the allocation trades belong in?  For
example, in your XML example, Forecast Global Fund has two accounts,
identified by XML ids  ACC0 and ACC1.  How do we know if the allocation
trade ABC101 is put in ACC0 or  ACC1?   I've looked a dozen times to see
if it can be determined and I can't find it.   Nothing appears to
reference either account. It seems to me that the account is only able to
be determined (inferred) if we assume a one-to-one relation between
parties and accounts, which violates my going-in assumption.  But maybe
I'm missing something.

 

So we are in 100% agreement that Matthew's model represents all of the
entities we need.  The issue is only that the relationship between the
trade and the account appears to be missing.  As I see it, it could either
be added to the tradeSide or to the trade itself.  In my work I've chosen
to put it in the tradeSide, but it could also go somewhere in trade.

 

As for the point about multiple clearing brokers, that has no effect on
the argument other than increasing the number of accounts a particular
party may own (i.e. at different brokers), which increases the difficulty
in determining which account a trade belongs in.  Other than that, as you
say the model can represent it.

 

There is no problem in representing the accounts themselves or the
parties, or even the relationships between them. The issue is how these
different entities relate to a trade.

 

Sorry if this seems like I'm picking on a small point, but the issue of
which specific account a trade belongs to is of considerable interest when
using accounts.

 

 

Brian Lynn, CTO

Global Electronic Markets,  <http://global-emarkets.com>
http://global-emarkets.com

High-speed FpML matching, reconciliation, and validation:

 <http://fpml-mediator.com> http://fpml-mediator.com

 

  _____  

From: Marc Gratacos [mailto:MGratacos@xxxxxxxx] 
Sent: Wednesday, February 02, 2005 6:32 PM
To: mwg@xxxxxxxxxxxxxxxxxxxxxx
Subject: RE: FpML-MWG40 More on accounts and account references

 

Brian,

 

Let me see if I understand this. I gave it a shot and I created an example
of allocation see xml file. It may help for the discussion.

 

I did in two steps. First there is a block trade between UBS and Forecast
Capital Partners. Then there are two allocated trades. The first is
between Forecast Capital Partners and Forecast Global Fund. The second
allocated trade is between Forecast Capital Partners and Forecast Asia
Fund.

 

Each one of the funds has two accounts at Morgan Cabot. 

 

As I see it, there is no "trade on behalf of" because there are two steps
so I didn't include tradeSide elements. But I guess I could do it to
specify that the settler is Morgan Cabot. Anyway, I think the issue here
is regarding the account information.

 

>>In theory, the same client might use multiple clearing brokers to handle
its trades, so there are lots of choices about how the trade is handled.

This piece is what I don't understand. Are you saying that within a single
allocated trade a fund may use multiple clearing brokers? The model right
now allows a fund to reference a single settler (Morgan Cabot in our
case). 

 

Best Regards,

-Marc

+1-212-901-6028

 

-----Original Message-----
From: Brian Lynn [mailto:brian.lynn@xxxxxxxxxxxxxxxxxxx] 
Sent: February 02, 2005 12:35 PM
To: mwg@xxxxxxxxxxxxxxxxxxxxxx
Subject: RE: FpML-MWG40 More on accounts and account references

 

Matthew -

 

Thanks for this - I think I partly understand this, but not fully.  I
think I understand the distinction below between "account" and "service
account", but I haven't seen this before in the model.  I also don't
really understand why the (non-service) account in the model below is that
important to FpML.  Grouping the service accounts together in a customer
relationship ("sales account") seems something internal to the service
provider.  

 

I thought it might be useful to describe the problem that I am trying to
solve with this model.

 

I am working with client, Citco (a fund administrator), that wishes to
represent trades done by its clients.  In its internal database, it has a
field called "client".  But in the FpML representation of the trades,
Citco doesn't even necessarily appear as a party, since its relationship
with its clients isn't that relevant for recording activities and
positions, and the role of "client" is essentially irrelevant or
ambiguous, since the different parties are clients of each other for a
variety of reasons. Also, Citco's account relationships aren't relevant -
what is relevant is the execution and clearing accounts that its clients
(or its clients' funds) maintain at various clearing brokers.  So Citco
needs to represent the activities of the fund managers and funds that it
is supporting.

 

A typical scenario might be as follows:

 

Assume that we have the following (imaginary) legal entities and accounts:

 

A fund manager, Forecast Capital Partners.

 

Forecast has two funds (each of which is a legal entity):

- Forecast Global Fund

- Forecast Asia Fund

 

Forecast clears through a clearing broker, Morgan Cabot (also, of course,
a legal entity).

 

Forecast typically executes its trades through its own legal entity, then
allocates them to the two funds for clearing.

 

Each of the two funds has multiple (service) accounts at Morgan Cabot,
e.g. to segregate short term/position taking trades from long term asset
appreciation trades.

 

Now a specific trade by Forecast might be allocated out to both funds, and
to any of the trading accounts used by each fund.  In theory, the same
client might use multiple clearing brokers to handle its trades, so there
are lots of choices about how the trade is handled.

 

I'd like to make sure that the model we come up with both allows this
scenario to be represented and makes it clear what the relationships are,
without forcing parties to be duplicated if clients have multiple
relationships with service providers.

 

This is the reason that I am concerned about explicitly representing the
account relationships.  In the current model I don't understand how to
track all of this without creating new references in the "TradeSide"
model, or without duplicating party elements for each fund/account
combination (which I consider unacceptable).

 

Regards,

 

 

 

Brian Lynn, CTO

Global Electronic Markets,  <http://global-emarkets.com>
http://global-emarkets.com

High-speed FpML matching, reconciliation, and validation:

 <http://fpml-mediator.com> http://fpml-mediator.com

 

  _____  

From: matthew.d.rawlings@xxxxxxxxxxxx
[mailto:matthew.d.rawlings@xxxxxxxxxxxx] 
Sent: Tuesday, February 01, 2005 2:41 PM
To: mwg@xxxxxxxxxxxxxxxxxxxxxx
Cc: mwg@xxxxxxxxxxxxxxxxxxxxxx
Subject: RE: FpML-MWG40 More on accounts and account references

 


I tried an ER and a UML diagram but they reveal nothing unless the
definition of the entities is shared. 

Account is defined as the representation of a client Party at a Party
providing a service to the Client. A Party does not own Accounts, it is
the Account. This use of the word is as in a "Sales Account" or "Account
Management" - it refers to the Customer in it's entirety. 

The current model is: 



If it isn't clear to Brian then it isn't clear enough and needs improving.
Perhaps we should rename Account as "Client" or "Customer"? The problem
with this is that being a "Client" or a "Customer" is too perspective
specific. 


Matthew Rawlings
+44 791 539 7824 




 

Brian Lynn <brian.lynn@xxxxxxxxxxxxxxxxxxx> 

01/02/2005 15:33 
Please respond to mwg 

        
        To:        mwg@xxxxxxxxxxxxxxxxxxxxxx 
        cc:         
        Subject:        RE: FpML-MWG40 More on accounts and account
references




Thanks, Matthew. 
  
Your definition seems to imply that we need multiple party elements for
the same legal entity if it uses multiple accounts, which seems confusing
to me.   
  
Also, it seems to me that accounts, like parties, can play different
roles:  some might be used for tracking positions in financial instruments
(like swaps, or stocks), and some might be used to track cash used for
settling trades or required payments for those financial instruments.
Typically you would have both in a transaction.  It's not clear to me how
the existing proposal clearly specifies how which accounts are to be used
for these different purposes. 
  
It seems to me that an ER model would be useful here ... 
  
e.g. 
  
Party - Manages - Account 
Party - OwnsAssetsIn - Account 
  
Asset - RecordedIn - Account 
  
Etc, etc.. 
  
Once we have modeled this in a way that we can agree with, we can convert
to XML references.... 
  
  
Brian Lynn, CTO 
Global Electronic Markets,  <http://global-emarkets.com/>
http://global-emarkets.com 
High-speed FpML matching, reconciliation, and validation: 
 <http://fpml-mediator.com/> http://fpml-mediator.com 
  

 

  _____  


From: matthew.d.rawlings@xxxxxxxxxxxx
[mailto:matthew.d.rawlings@xxxxxxxxxxxx] 
Sent: Tuesday, February 01, 2005 10:07 AM
To: mwg@xxxxxxxxxxxxxxxxxxxxxx
Cc: mwg@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: FpML-MWG40 More on accounts and account references 
  

My apologies for not being able to speak at the meeting or answer earlier.
I have been unwell. 

I believe this is easily explainable. We have different definitions of
account in play. The definition I have is that of each Party being a
single Customer/Client/Account at another Party. This is the "Account
Management" view of an "Account". The definition Brian has used is of an
account as a specific service taken by the Client. This is a reasonable
interpretation. I believe this shows we need to clarify the definition
further. This is always a challenge as the terms are so overloaded. I
believe this should answer all the points. 




Matthew Rawlings
+44 791 539 7824 


  

Brian Lynn <brian.lynn@xxxxxxxxxxxxxxxxxxx> 

19/01/2005 13:44 
Please respond to mwg 

        
       To:        mwg@xxxxxxxxxxxxxxxxxxxxxx 
       cc:         
       Subject:        FpML-MWG40 More on accounts and account references





While I'm not an expert in trade settlement, it seems to me that we may
actually need two different kinds of accounts (or account roles) for
properly representing our trades. 
 
1) trading or clearing accounts, for holding/clearing positions in
securities or OTC instruments at, say, a prime broker. 
2) settlement accounts, for holding cash positions, and settling trades.

 
I believe that both of these types of accounts can be represented using
Matthew's existing proposal.  In fact, the example Matthew provided seems
to imply this, although I can't find any document describing how the
accounts are to be used.  (The example does show an account at the
"settler" party and an account at the "clearer" party, so perhaps these
are intended to be the settlement and trading accounts).  However, once
again a single party could have multiple settlement and clearing accounts
(even at the same place), so an explicit reference should be provided, so
we know which account is intended for what purpose. 
 
I think that this could be done by extending the TradeSide structure with
a settlementAccount reference and clearingAccount reference.  Perhaps
these could be grouped with the settler and clearer party references. 
 
We might also consider adding an account type element to Account, to
indicate what it holds (securities or money). 
 
Brian Lynn, CTO 
Global Electronic Markets,  <http://global-emarkets.com/>
http://global-emarkets.com 
High-speed FpML matching, reconciliation, and validation: 
 <http://fpml-mediator.com/> http://fpml-mediator.com 
 
  

<<attachment: winmail.dat>>