Purchase Contract Request
When a bid is accepted the broker will register all necessary data in their system. Eventually the parties will sign the purchase agreement, either digitally or on paper.
The bank can request the contract data, which may or may not contain the signed document depending on how far the broker’s process has come.
If significant data changes, the broker will push updates to all banks that have requested contract data. Examples of significant changes can be:
The contract is signed.
Properties are added or removed
Buyers are added or removed
For a complete list, see the specification from DSVE/Bits Norge.
The next step in the process for the bank is to send a bank intention to the broker so the bank and the broker can agree on the registration method (tinglysingsmetode) - paper or digital.
The model
In DSVE there are three message types associated with the request and exchange of the buyer contract data:
The request from the bank
The initial response from the broker
Change notification messages from the broker
The Buyer contract request (from the bank)
This request is simple and contains basically the personal number of the buyer.
The response message (from the broker)
This is the tricky part. Depending on how many, if any, settlements that matches the personal number, the broker can respond with zero, one or many contracts (represented in EPS as Settlements). It is the responsibility of the bank to pick the correct one if there are many.
Change messages (from the broker)
If any of the important data fields in the buyer contract changes after a bank has requested the buyer contract, a message will be sent to the bank with the updated buyer contract data. This message will contain data about only the one settlement that was changes, not all the settlements that was potentially returned in response to the request (the above message).
The EPS model vs DSVE (message) model
One buyer contract request is identified by a unique id. After the broker has responded, one request will reference/link to zero, one or many buyer contracts.
Data
A buyer contract in DSVE is represented as a Settlement in EPS. Thus a buyer contract request will link to zero, one or many Settlements. The data in the buyer contract can be read by the bank using the existing Settlement resource in EPS
Rendering
For each DSVE model there is a corresponding XSLT file that can be used to convert the XML data to HTML or PDF. For the bank to download a PDF of the latest contract data, the bank will have to provide both the request uuid and the settlement uuid in order for us to render the latest version, which can be either the initial response from the broker or a later change on that particular settlement/contract.
If there were three contracts/settlements in the response from the broker and no later changes, a rendering of the data will contain one page for each settlement as the DSVE message contains multiple contracts.
DSVE data
All messages specified by DSVE are in XML format. We propose that it is easier for our customers to parse the Json format from our Settlement resource in EPS, but if there is a need for accessing the XML data (raw data from the broker) these messages can be made available for out customers as well.
The signed buyers contract
A PDF og the actually signed buyers contract will be available when the broker has made the file available to us. This must not be confused with a PDF rendering of the structural data in PDF format mentioned above.
Events
If the broker is an Ambita broker, the bank will get an immediate response on the request. If the request is sent to an external broker, an event BUYER_CONTRACT_RESPONSE_RECEIVED
will be generated for the bank when the response is available. Similarly an event BUYER_CONTRACT_CHANGED
will be created for the bank if there is a change in one of the contracts/settlements requested.
Note: The event BUYER_CONTRACT_RESPONSE_RECEIVED
will be the first event generated by EPS that dows not reference a Settlement uuid, which is a braking change. We have therefore added a new query parameter contractevents=true
that you must add when querying for events in order to receive these new “braking changes” events.