Create the dealers

[thinkjrs]

Creating the Dealer

The dealer in sim-exchange comprises two entities on sim-exchange, the

• investor-user dealer and the
• asset-user dealer.

Each dealer is charged with maximizing its own utility, acting in full competition with its user base and the other dealer. This ensures fiduciary-like action for the platform operator as a whole, as both opposing dealers' competition should maximize their opponent's clients' gain.

Maximizing utility

Completely asymmetric information presents a challenge for a digital exchange with the true intention of avoiding agent-principal relationships w.r.t. holding client assets.

One way to get around this is to split the overall dealer's responsibility (the platform, e.g. Musicfox with its Musicfox Artist and Investor Platform) into two.

InvestorDealer

This dealer offers investor-users a price for their up-front cash flow in exchange for some uncertain cash flows in the future, which it trades bid-side behind the scenes with the AssetDealer. Because the InvestorDealer seeks to maximize its wealth (utility) in competition with the AssetDealer and its investor-users, utility for the AssetDealer's client, the asset-user, is maximized.

AssetDealer

On the contrary, this dealer offers asset-users a price for their their uncertain future cash flows in exchange for immediate, certain lump-sum cash. The AssetDealer offers its asset-users this via bid-side trades with the InvestorDealer. The AssetDealer maximizes the investor-user's utility because the AssetDealer seeks to maximize its wealth in competition with the InvestorDealer and its asset-user clients, in turn providing its best estimate of price for the investor-users' immediate cash flows.

Dealer API

import abc

class Dealer:
    def __init__(self):
        """
        Datastructures for each piece of a dealer application. This class
        is inherited by specialized dealers -- the InvestorDealer and AssetDealer.

        Items handled by a dealer:
        - `CashFlowPricer`
        - `OPL`
        - `MatchingAlgo`
        - `QueueUpdater`
        - `OrderSignaler`
        - `oppositionView`
        """
        pass

    @classmethod
    @abc.abstractmethod
    def queueUpdater(cls):
        pass

    @classmethod
    @abc.abstractmethod
    def orderSignaler(cls):
        pass

    @classmethod
    @abc.abstractmethod
    def oppositionView(cls):
        pass

class InvestorDealer(Dealer):
    def __init__(self):
        """
        # `InvestorDealer`
        A dealer to interact with investor users, offer those users prices,
        and potentially trade with the opposing asset dealer. 

        The `InvestorDealer` inherits a `Dealer` class and implements or
        instantiates the following, unique to the `InvestorDealer`:
        - `CashFlowPricer`
        - `OPL`
        - `MatchingAlgo`
        - `InvestorDemandQueue`
        - `queueUpdater`
        - `orderSignaler`
        - `oppositionView`
        """
        self.cfp = CashFlowPricer(...)
        self.malgo = MatchingAlgo(...)
        self.opl = OPL(...)
        self.queue = InvestorDemandQueue(...)

    def queueUpdater(self):
        pass # call with custom params using super()
    def orderSignaler(self):
        pass # call with custom params using super()
    def oppositionView(self):
        pass # super() to call base class method w/custom params

class AssetDealer(Dealer):
    def __init__(self):
        """
        # `AssetDealer`
        A dealer to interact with asset users, offer those users prices,
        and potentially trade with the opposing investor dealer. 

        The `AssetDealer` inherits a `Dealer` class and implements or
        instantiates the following, unique to the `AssetDealer`:
        - `CashFlowPricer`
        - `OPL` (optimization possibilities loop)
        - `MatchingAlgo`
        - `AssetDemandQueue`
        - `queueUpdater`
        - `orderSignaler`
        - `oppositionView`
        """
        self.cfp = CashFlowPricer(...)
        self.malgo = MatchingAlgo(...)
        self.opl = OPL(...)
        self.queue = AssetDemandQueue(...)

    def queueUpdater(self):
        pass # call with custom params using super()
    def orderSignaler(self):
        pass # call with custom params using super()
    def oppositionView(self):
        pass # super() to call base class method w/custom params

class CashFlowPricer:
    """
    # `CashFlowPricer`
    Given an investor-user or asset-user cash flows return a "price". 

    This price is the discounted future value of all cash flows between
    two dates.
    """
    pass

class OPL:
    """
    # `OPL` - Optimization Possibilities Loop

    Given strips of supply and demand calculate possible portfolio combinations.

    """
    def __init__(self, asset_queue: list, investor_queue: list):
        """
        ## Parameters
        - `asset_queue`: a list of asset user Python Dataclasses
        - `investor_queue`: a list of investor user Python Dataclasses
        """
        self.asset_queue = asset_queue
        self.investor_queue = investor_queue
        self.combos = ... # dict-like storage of fully-allocated combinations
        self.queue = ... # FIFO queue to send chunks of ports to MatchingAlgo

class MatchingAlgo:
    """
    # `MatchingAlgo`

    Given some tail probabilities tolerance and possible combinations
    dictionary, return a ranked list of matches within the tolerance.
    """
    pass

Tasks

Add to these as/if/when requirements evolve!

• [ ] Assess and critique design choices
• [ ] Naive implementation of the following:
• [ ] Dealer base class
• [ ] InvestorDealer
• [ ] AssetDealer
• [ ] OPL See issue #18 comment
• [ ] CashFlowPricer
• [ ] Coordination of interface with DemandQueue issue 15
• [ ] Coordination of interface with MatchingAlgo issue 2
• [ ] Mathematical & technical structural documentation (describing the dealer schematics succinctly)

Tests

Tests for this are located under backend/application/test. We use py.test for our test-suite runner and unit testing here.

Filename targets:

• test_Dealer.py

[sssyzzz]

Hi Jason, here's some conceptual questions about the model we're building.

1. Definition of price: For assets, It’s the price of the asset, which we measure with something like discounting cash flow? What about the investors? According to the issue’s descriptions: “This dealer offers investor-users a price for their up-front cash flow in exchange for some uncertain cash flows in the future” They come with real cash so how and why are we pricing their money? Sounds like we’re offering a price for all the cash flow provided by the investor. So, is it that an investor comes with $1K, and we might tell him that the “price” of his cash flow is not $1K?

2. The dealers have a queue for demands for both sides. But we wanted to diversify. How do we diversify if we’re taking demands in a queue? What’s the meaning of the sequence in the queue?

3. What size of investments are we expecting from each investor? Under certain scenarios I’m not sure how to diversify the source of investment of each asset user. For example, if asset users come with demands for thousands of bucks, but rich investors come with millions, then naturally the investors can completely fulfill demands from multiple matched asset users. Do we worry about this or do we tackle with this in some way?

4. What is considered as inventory in our scenario? I thought the inventory models are meant to manage return and risk in trading when we are exposed to the risk from what we are holding. What’s the risk of holding unfilled demands for the asset/investment dealers? And could you explain a bit on whether inventory and demand queue are conceptually pointing to the same thing?

5. Are the parameters for pricing same as those in matching investor/assets?

6. The dealer class needs to implement a utility function. Do both sides have different utility functions? For investors, what is this utility function’s inputs? Returns/variance, or return/variance + other preference parameters? For assets, what is their utility function about? I understand that for investors there is uncertainty on the future cash flow, so there is definitely something to optimize. But what’s the utility of an asset user like?

7. Could you explain a bit more on this from description: “The AssetDealer maximizes the investor-user’s utility because the AssetDealer seeks to maximize its wealth in competition with the InvestorDealer and its asset-user clients, in turn providing tis best estimate of price for the investor-users’ immediate cash flows.” How does this competition work?

[thinkjrs]

Hi Jason, here's some conceptual questions about the model we're building.

1. Definition of price: For assets, It’s the price of the asset, which we measure with something like discounting cash flow? What about the investors? According to the issue’s descriptions: “This dealer offers investor-users a price for their up-front cash flow in exchange for some uncertain cash flows in the future” They come with real cash so how and why are we pricing their money? Sounds like we’re offering a price for all the cash flow provided by the investor. So, is it that an investor comes with $1K, and we might tell him that the “price” of his cash flow is not $1K?

We tell the investor what proportion of uncertain future cash flows her immediate cash flow can acquire. Therefore we're not saying $1000 < $1000; we're saying that $1000 gets you ~ XYZ future cash flows. Because the number of investor-users and asset-users is unlikely to be the same, and those users are unlikely to have the same data (e.g. risk + return), this number presented is unlikely to be constant.

2. The dealers have a queue for demands for both sides. But we wanted to diversify. How do we diversify if we’re taking demands in a queue? What’s the meaning of the sequence in the queue? We're diversifying "heuristically" via many cash flow packages for their users, if those users' cash flows were demanded by the opposing side.

Think about making our dealer setup inside of a US 10-year Treasury bond. We have users who want to buy the bond and those who want to sell it. Now imagine there's no market for the bonds but we are allowed to deal the cash flows of the bond. One of our dealers would take money in (users wishing to purchase the bonds' cash flows) and another would disburse funds (users wishing to sell the bonds' cash flows).

3. What size of investments are we expecting from each investor? Under certain scenarios I’m not sure how to diversify the source of investment of each asset user. For example, if asset users come with demands for thousands of bucks, but rich investors come with millions, then naturally the investors can completely fulfill demands from multiple matched asset users. Do we worry about this or do we tackle with this in some way? No need to worry about this here: the Platform operator (owner of the dealers) in this scheme are responsible for ensuring the queue doesn't become completely lopsided.

In fact, you raise a critical feature/benefit of Musicfox: we have an absolutely wild imbalance in funding opportunity for artists and musicians, as the demand for their risk premia in nominal terms is factors of 10 larger than what is "spendable" in the industry of music. Yet, that is 😉.

4. What is considered as inventory in our scenario? I thought the inventory models are meant to manage return and risk in trading when we are exposed to the risk from what we are holding. What’s the risk of holding unfilled demands for the asset/investment dealers? And could you explain a bit on whether inventory and demand queue are conceptually pointing to the same thing?

What is considered as inventory in our scenario? So we (you + me) need to decide how to treat inventory. In simple microstructure models "inventory" is the value process of the dealers' principal positions. So let's assume here that all users in a demand queue are held as a dealers' inventory.

💥 inventory and demand queue are conceptually pointing to the same thing 💥

5. Are the parameters for pricing same as those in matching investor/assets?
6. The dealer class needs to implement a utility function. Do both sides have different utility functions?

In concept they absolutely have different utility. For now, let's model them with the same model but separately implement/run that model. This will allow us to "get it working" and then add in specific utility functions later.

Let's assume simple power utility:

For investors, what is this utility function’s inputs? Returns/variance, or return/variance + other preference parameters? For assets, what is their utility function about? I understand that for investors there is uncertainty on the future cash flow, so there is definitely something to optimize. But what’s the utility of an asset user like?

For now, lets keep the actual utility discussion very "conceptual". We're faced with little historical data and want to make sure that down the road we're actually able to generally model some type of utility function for both asset users and investor users that captures their changing risk preferences through time. I suspect attacking "platform" problems in the tech industry is the only way we're going to learn about any of this.

7. Could you explain a bit more on this from description: “The AssetDealer maximizes the investor-user’s utility because the AssetDealer seeks to maximize its wealth in competition with the InvestorDealer and its asset-user clients, in turn providing tis best estimate of price for the investor-users’ immediate cash flows.” How does this competition work?

So in concept each dealer should want to max its wealth. Because it can only trade with the other dealer and one user, the opposing dealer's user should benefit.

Think of it this way

Think about calculating long-term profits in a two-dealer market where those dealers had the exact same capability, information, people: this profit should be ~ 0, with the simple assumption of each dealer maximizing its wealth.

Dealer diagram (high level)

_Note: we might need more machinery or less!