WO2024151206A1

WO2024151206A1 - Method and system for calculating a downstream price

Info

Publication number: WO2024151206A1
Application number: PCT/SG2023/050017
Authority: WO
Inventors: Yu Xuan YUAN
Original assignee: Tenpay Global Pte. Ltd.
Priority date: 2023-01-09
Filing date: 2023-01-09
Publication date: 2024-07-18

Abstract

In some aspects, a computer-implemented method for calculating a downstream price by applying two or more layers of markup to an upstream price, the two or more layers of markup being configured by separate entities in a supply chain, is provided. The method may comprise storing, in a central database, configuration data for the two or more layers of markup; in response to an inquiry for the downstream price: retrieving, by at least one processor, the configuration data for the two or more layers of markup from the central database; and calculating, by the at least one processor, the downstream price based on the upstream price and the retrieved configuration data for the two or more layers of markup, wherein the at least one processor executes a calculation algorithm for the two or more layers of markup.

Description

METHOD AND SYSTEM FOR CALCULATING A DOWNSTREAM PRICE

TECHNICAL FIELD

[0001] Various aspects relate to methods and systems for calculating a downstream price by applying two or more layers of markup to an upstream price, the two or more layers of markup being configured by separate entities in a supply chain for providing a good, a service or a currency.

BACKGROUND

[0002] A supply chain for providing a good, a service or a currency usually contains two or more entities, which apply two or more layers of markup, i.e., a sequence of markups at each layer of the supply chain. For instance, the selling price of a producer becomes the cost of a wholesaler, and this cost is added to a wholesale markup which becomes the selling price of the wholesaler; the selling price of the wholesaler becomes the cost of a retailer, and this cost is again added to a retail markup which becomes the selling price of the retailer. In some cases, in order to attract certain customers, an entity in the supply chain may offer to these customers a selling price lower than its cost, i.e., by applying a negative markup, or, in other words, giving a discount.

[0003] A supply chain for providing a currency, which may also be viewed as providing a currency as a good and/or currency exchange as a service, may include a liquidity provider, which is an institution, such as a bank or a large trading firm, or an individual that provides capital to finance transactions and acts as a market maker in the foreign exchange market. The supply chain may further include an exchange platform, which provides quotes to the customer market based on the exchange rate information and liquidity situation in the foreign exchange interbank market. The exchange platform may offer its customers a bid/ask price that includes a markup on top of the platform benchmark price, i.e., the exchange rate at which the exchange platform obtains liquidity from the liquid providers, to generate profit for the exchange platform. A further entity located at a lower layer of the supply chain may be an internal business unit of the exchange platform. Internal and external merchants located at an even lower layer of the supply chain are not directly connected to the exchange platform, but indirectly through various internal business units of the exchange platform. These business units apply additional markups while providing personalized services based on the merchants' individual needs. Examples of such business units may be business units for online money transfer, corporate currency exchange, etc. Examples of internal and external merchants directly served by the business units may include online e- commerce or e-transaction platforms. These merchants apply further markups when providing quotes to users, i.e., specific customers of each merchant.

[0004] In such a currency supply chain, demands at each layer are diverse. For example, the business unit for corporate currency exchange needs to provide different merchants with different exchange rates, and an e-commerce platform, as a merchant, needs to provide different users with different exchange rates. In the process of distributing exchange rates by the exchange platform, the exchange rates are passed through the business unit layer, merchant layer, and finally provided to the users. The entities at each layer can adjust the exchange rate offered to the entities at the lower layer by way of markup, including negative markup, i.e., discount.

[0005] Conventionally, each entity itself takes the price offered from the upper layer as its cost, and then quotes a price based on the markup calculation, and calculates the corresponding profit or loss based on the difference between the quoted price and its cost. In the conventional solution, the calculation at each layer is distributed in their own computing systems involving separate hardware and/or separately developed software. The computing systems of each layer obtain the price of the upper layer via an interface, complete the relevant calculation independently, and distribute the calculated prices to the computing systems at the lower layer. Since the computing systems are independent of each other, the configuration of markup also needs to be managed independently.

[0006] The conventional solution has several shortcomings. First, the markup calculation is scattered in different computing systems at different layers, which cannot guarantee the consistency of computing details and greatly increases the cost of understanding and the probability of error. Furthermore, various similar but not identical markup configurations are scattered in different databases, resulting in data redundancy and failure to ensure data consistency, which also greatly increases operational costs. Last but not the least, prices, especially currency exchange rates change frequently, and most merchants, especially external merchants, lack the ability to handle the operation and calculation of markup in real time.

[0007] A need exists to provide an improved method and system for calculating a downstream price by applying two or more layers of markup to an upstream price, the two or more layers of markup being configured by separate entities in a supply chain for providing a good, a service or a currency.

SUMMARY

[0008] According to a first aspect of the present disclosure, a computer-implemented method for calculating a downstream price by applying two or more layers of markup to an upstream price, the two or more layers of markup being configured by separate entities in a supply chain, is provided. The method may comprise storing, in a central database, configuration data for the two or more layers of markup; in response to an inquiry for the downstream price: retrieving, by at least one processor, the configuration data for the two or more layers of markup from the central database; and calculating, by the at least one processor, the downstream price based on the upstream price and the retrieved configuration data for the two or more layers of markup, wherein the at least one processor executes a calculation algorithm for the two or more layers of markup.

[0009] According to a second aspect of the present disclosure, a system for calculating a downstream price by applying two or more layers of markup to an upstream price, the two or more layers of markup being configured by separate entities in a supply chain, is provided. The system may comprise a central database configured to store configuration data for the two or more layers of markup; and at least one processor configured to, in response to an inquiry for the downstream price: retrieve the configuration data for the two or more layers of markup from the central database; and calculate the downstream price based on the upstream price and the retrieved configuration data for the two or more layers of markup, wherein the at least one processor is configured to execute a calculation algorithm for the two or more layers of markup.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Throughout the drawings, it should be noted that like reference numbers are used to depict the same or similar elements, features, and structures. The drawings are not necessarily to scale, emphasis instead generally being placed upon illustrating aspects of the disclosure. In the following description, some aspects of the disclosure are described with reference to the following drawings, in which: FIG 1. is a block diagram showing an example of a supply chain for providing a currency, which may also be viewed as providing a currency as a good and/or currency exchange as a service, according to an embodiment of the present disclosure;

FIG. 2 is a flow chart showing an example of a method according to an embodiment of the present disclosure;

FIG. 3 is a diagram showing an example of a database/table design according to an embodiment of the present disclosure;

FIG. 4 is a block diagram showing an example of money movement within a supply chain for providing a currency, which may also be viewed as providing a currency as a good and/or currency exchange as a service, according to an embodiment of the present disclosure;

FIG. 5 is a sequence diagram showing an example of a method according to an embodiment of the present disclosure;

FIG. 6 is a sequence diagram showing an example of a detailed internal sequence of the process “Obtain Markup Configuration” in Fig. 5; and

FIG. 7 is a sequence diagram showing an example of a detailed internal sequence of the process “Calculate Customer Quotation” in Fig. 5.

DETAILED DESCRIPTION

[0011] The following detailed description refers to the accompanying drawings that show, by way of illustration, specific details and aspects in which the disclosure may be practiced. One or more aspects are described in sufficient detail to enable those skilled in the art to practice the disclosure. Other aspects may be utilized and structural, logical, and/or electrical changes may be made without departing from the scope of the disclosure. The various aspects of the disclosure are not necessarily mutually exclusive, as some aspects can be combined with one or more other aspects to form new aspects or embodiments. Various aspects are described in connection with methods and various aspects are described in connection with devices. However, it may be understood that aspects described in connection with methods may similarly apply to the devices, and vice versa.

[0012] It should be understood that the singular terms "a", "an", and "the" include plural references unless context clearly indicates otherwise. Similarly, the word "or" is intended to include "and" unless the context clearly indicates otherwise.

[0013] It will be further understood that the terms “comprise” (and any form of comprise, such as “comprises” and “comprising”), “have” (and any form of have, such as “has” and “having”), “include” (and any form of include, such as “includes” and “including”), and “contain” (and any form of contain, such as “contains” and “containing”) are open-ended linking verbs. As a result, a method or device that “comprises,” “has,” “includes” or “contains” one or more steps or elements possesses those one or more steps or elements, but is not limited to possessing only those one or more steps or elements. Likewise, a step of a method or an element of a device that “comprises,” “has,” “includes” or “contains” one or more features possesses those one or more features, but is not limited to possessing only those one or more features. Furthermore, a device or structure that is configured in a certain way is configured in at least that way, but may also be configured in ways that are not listed.

[0014] Approximating language, as used herein throughout the specification and claims, may be applied to modify any quantitative representation that could permissibly vary without resulting in a change in the basic function to which it is related. Accordingly, a value modified by a term or terms, such as “about,” “substantially”, is not limited to the precise value specified but within tolerances that are acceptable for operation of the embodiment for an application for which it is intended. In some instances, the approximating language may correspond to the precision of an instrument for measuring the value.

[0015] The terms “at least one” and “one or more” may be understood to include a numerical quantity greater than or equal to one (e.g., one, two, three, four, [...], etc.). The term “a plurality” may be understood to include a numerical quantity greater than or equal to two (e.g., two, three, four, five, [...], etc.). The phrase “at least one of’ with regard to a group of elements may be used herein to mean at least one element from the group consisting of the elements. For example, the phrase “at least one of’ with regard to a group of elements may be used herein to mean a selection of: one of the listed elements, a plurality of one of the listed elements, a plurality of individual listed elements, or a plurality of a multiple of listed elements.

[0016] The words “plural” and “multiple” in the description and in the claims expressly refer to a quantity greater than one. Accordingly, any phrases explicitly invoking the aforementioned words (e.g., “a plurality of (objects)”, “multiple (objects)”) referring to a quantity of objects expressly refer to more than one of the said objects. The terms “group (of)”, “set (of)”, “collection (of)”, “series (of)”, “sequence (of)”, “grouping (of)”, etc., and the like in the description and in the claims, if any, refer to a quantity equal to or greater than one, i.e. one or more.

[0017] The term “data” as used herein may be understood to include information in any suitable analog or digital form, e.g., provided as a file, a portion of a file, a set of files, a signal or stream, a portion of a signal or stream, a set of signals or streams, and the like. Further, the term “data” may also be used to mean a reference to information, e.g., in form of a pointer. The term “data”, however, is not limited to the aforementioned examples and may take various forms and represent any information as understood in the art. Any type of information, as described herein, may be handled for example via one or more processors in a suitable way, e.g., as data.

[0018] The term “database” refers to a collection of data organized, formatted, and stored in such a manner as to be capable of being retrieved and analyzed by execution of an appropriate program at one or more processors.

[0019] The terms “processor” or “controller” as, for example, used herein may be understood as any kind of entity that allows handling data. The data may be handled according to one or more specific functions executed by the processor or controller. Further, a processor or controller as used herein may be understood as any kind of circuit, e.g., any kind of analog or digital circuit. A processor or a controller may thus be or include an analog circuit, digital circuit, mixed-signal circuit, logic circuit, processor, microprocessor, Central Processing Unit (CPU), Graphics Processing Unit (GPU), Digital Signal Processor (DSP), Field Programmable Gate Array (FPGA), integrated circuit, Application Specific Integrated Circuit (ASIC), etc., or any combination thereof. Any other kind of implementation of the respective functions, which will be described below in further detail, may also be understood as a processor, controller, or logic circuit. It is understood that any two (or more) of the processors, controllers, or logic circuits detailed herein may be realized as a single entity with equivalent functionality or the like, and conversely that any single processor, controller, or logic circuit detailed herein may be realized as two (or more) separate entities with equivalent functionality or the like.

[0020] Differences between software and hardware implemented data handling may blur. A processor, controller, and/or circuit detailed herein may be implemented in software, hardware, and/or as a hybrid implementation including software and hardware.

[0021] The term “system” (e.g., computing system) detailed herein may be understood as a set of interacting elements, wherein the elements can be, by way of example and not of limitation, one or more mechanical components, one or more electrical components, one or more instructions (e.g., encoded in storage media), and/or one or more processors, and the like.

[0022] The term “first”, “second”, “third” detailed herein are used to distinguish one element from another similar element and may not necessarily denote order or relative importance, unless otherwise stated.

[0023] The term “third-party payment” detailed herein includes an independent institution having certain strength and credit guarantee, which, by signing contracts with financial institutions such as banks, provides a network payment mode interfaced with a bank payment system for a transaction payment platform. In the third-party payment model, a buyer (e.g., user, client) purchases the goods (e.g. product), using the account provided by the third-party platform to pay for the goods (e.g. pay to the third party), and the third party will notify the seller that the payment has been made and request the seller to deliver the merchant. After the buyer receives the goods, inspects the goods, and confirms them, the buyer notifies the third party to pay the seller. The third party then transfers the payment to the seller account.

[0024] The term “liquidity provider” detailed herein broadly include banks, financial institutions, principal trading firms (PTFs), and other providers of liquidity. Liquidity provision in modern markets requires diversity among liquidity providers to facilitate risk transfer and efficiently match buyers with sellers during continuous trading.

[0025] The term “exchange platform” detailed herein, and simply referred to as “platform” in some figures and table, may be the actual implementer of the solution of the present disclosure. In the third-party payment scenario, the exchange platform provides quotes to the customer market based on the exchange rate information and liquidity situation in the foreign exchange interbank market. [0026] The term “platform benchmark price” detailed herein refers to the exchange rate at which the exchange platform obtains liquidity from the liquid providers.

[0027] The term “business unit” detailed herein, and simply referred to as “business” in some figures and table, refers to internal units of the exchange platform. External merchants are not directly connected to the exchange platform, but indirectly through various internal business units. These business units charge fees while providing personalized services based on the merchant's needs. Examples of business units may include online money transfer, corporate currency exchange, etc.

[0028] The term “merchants” detailed herein refers to business (B-end) users who have signed contracts after being authenticated by the third-party payment platform, and supply transaction resources (goods, services, etc.) for ordinary users. Examples of merchants may include online e-commerce or e-transaction platforms.

[0029] The term “users” detailed herein refers to specific customers of each merchant.

[0030] The term “bid price” detailed herein refers to a price at which a buyer is ready to buy, and the bid price of the exchange platform is thus the trader's selling price. The term “ask price” detailed herein refers to a price at which a seller is ready to sell, and the ask price of the platform is thus the trader's buying price

[0031] The term “basis point”, abbreviated as “BPS” is a common unit of measurement for exchange rates and other percentages in finance. A basis point is equal to l/100th of 1% or 0.01% and is used to express the change in the value or rate of a financial instrument. The relationship between percentage change and basis points can be summarized as follows: 1% change = 100 basis points, 0.01% = 1 basis point.

[0032] The term “pip” is an acronym for percentage in point or price interest point. In finance, specifically in foreign exchange markets, a pip is a unit of change in an exchange rate of a currency pair. The major currencies are traditionally priced to four decimal places, and a pip is one unit of the fourth decimal place. While basis points are calculated by multiplying and dividing, pips are calculated by adding or subtracting.

[0033] The term “markup” detailed herein refers to the difference between the selling price and the cost. It is often expressed as a percentage over the cost.

[0034] The term “discount” detailed herein refers to a deduction from the cost. When the selling price is lower than the cost, i.e., when the markup is negative, a discount is offered.

[0035] The term “supply chain” detailed herein refers to a network of entities, including individuals, organizations, internal units of organizations, etc., who are involved in providing a good, a service or a currency.

[0036] The term “upstream” detailed herein relates to an earlier stage in a process or series of events, and, in a supply chain, a position closer to the origin or source of the good, service or currency. For example, an upstream price may refer to the original cost price of providing a good or a service before any mark-ups along the supply chain of providing the good and/or the service, or a price that is not the original cost price but is in comparison to a downstream price closer (in terms of its position in the supply chain) to the original cost price.

[0037] The term “downstream” detailed herein relates to a later stage in a process or series of events, and, in a supply chain, a position closer to the end-users. For example, a downstream price may refer to the end-user selling price of providing a good or a service after one or more layers of mark-ups configured or applied by various entities along the supply chain of providing the good and/or the service, or a price that is not the end-user selling price but is in comparison to an upstream price closer (in terms of its position in the supply chain) to the end-user selling price. [0038] The term “algorithm” detailed herein refers to a sequence of rigorous instructions to be executed by a computer to perform a calculation or another problem-solving operation. [0039] The term “subroutine” detailed herein refers to a sequence of program instructions that performs a specific task, packaged as a unit. This unit can then be used in programs wherever that particular task should be performed.

[0040] The term “service” or “microservice” detailed herein refers to services of small size and independent from each other. A service may be part of a larger software application. Each service has a distinct computer code, which can be developed by a development team, independently from other services. The team may alter, update or take down an existing service without needing to recreate and redeploy a whole application. Communication between services can be performed using dedicated Application Programming Interfaces (APIs). Details about the internal structure of each service are not shown to other services.

[0041] Various aspects of what is described herein seek to provide a method for calculating a downstream price by applying two or more layers of markup to an upstream price, the two or more layers of markup being configured by separate entities in a supply chain. The proposed method may include storing, in a central database, configuration data for the two or more layers of markup; in response to a request for the downstream price: retrieving, by at least one processor, the configuration data for the two or more layers of markup from the central database; and calculating, by the at least one processor, the downstream price based on the upstream price and the retrieved configuration data for the two or more layers of markup, wherein the at least one processor executes a calculation algorithm for the two or more layers of markup.

[0042] In some instances, aspects of the method described here provide technical improvements and advantages over conventional approaches. For example, the collection and storage of the configuration data for the two or more layers of markup in a central database allows various similar but not identical markup configurations to be centrally stored and managed, thereby ensuring data consistency, reducing data redundancy caused by data being scattered in various local databases, and saving operation costs of maintaining various local databases. The centrally stored markup configuration data can also be easily retrieved and used for the calculation of the downstream price. The calculation of the downstream price based on the upstream price and the retrieved configuration data for the two or more layers of markup by executing a calculation algorithm, in particular, a uniform one, for the two or more layers of markup ensures the consistency of computing details, greatly reduces the probability of error, and, if errors are present, allows easier tracking of the sources of errors. This is an improvement over the prior art where entities at different layers of the supply chain develop their own computer programs for their respective markup calculation so that no consistent calculation algorithm can be maintained. For example, different rounding rules, including round-up, round-down, etc. may be used, and different levels of accuracy may be chosen in different calculation algorithms, resulting in inconsistent calculation results and great difficulties in error tracking. Last but not the least, the centrally developed computing system renders the various local computing systems scattered at different layers of the supply chain no longer necessary. Individual entities in the supply chain only need to perform simple configurations for their markup activities. Costly system development and maintenance, and duplication of work can be avoided.

[0043] The following examples pertain to various aspects of the present disclosure.

[0044] According to an example, a computer-implemented method is provided for calculating a downstream price by applying two or more layers of markup to an upstream price, the two or more layers of markup being configured by separate entities in a supply chain, the method comprising: storing, in a central database, configuration data for the two or more layers of markup; in response to a request for the downstream price: retrieving, by at least one processor, the configuration data for the two or more layers of markup from the central database; and calculating, by the at least one processor, the downstream price based on the upstream price and the retrieved configuration data for the two or more layers of markup, wherein the at least one processor executes a calculation algorithm for the two or more layers of markup.

[0045] Optionally, the upstream and downstream prices are prices of a good, a service or a currency, and the supply chain is for providing the good, the service or the currency.

[0046] Optionally, the calculation algorithm is uniform for the two or more layers of markup.

[0047] Optionally, the step of calculating the downstream price comprises: calculating an intermediate price by executing the calculation algorithm with the upstream price and a first layer of markup as input values; and calculating the downstream price or a further intermediate price by executing the calculation algorithm with the intermediate price and a second layer of markup as input values.

[0048] Optionally, the step of calculating the downstream price is executed by a microservice.

[0049] Optionally, the configuration data for the two or more layers of markup comprises, for each layer, a value of the markup, and an identifier of the entity configuring the markup.

[0050] Optionally, the value of the markup is uniformly expressed as a base point or as a percentage in point.

[0051] Optionally, the configuration data for the two or more layers of markup further comprises, for each layer, an identifier of the entity to which the markup is offered, and/or an identifier of a good type, service type or currency type associated with the markup. [0052] Optionally, the configuration data for the two or more layers of markup further comprises, for each layer, an identifier of a buying currency type and an identifier of a selling currency type associated with the markup.

[0053] Optionally, the method further comprises storing, by the at least one processor, in the central database, the calculated downstream price and/or intermediate calculation results including an intermediate price calculated by applying a first layer of markup to the upstream price.

[0054] Optionally, the method further comprises: calculating, by the at least one processor, profits and/or losses for the respective entities resulted from the two or more layers of markup, the profits and losses being resulted from positive and negative markups, respectively; and storing, by the at least one processor, in the central database, the calculated profits and/or losses in respective accounts of the respective entities.

[0055] Optionally, the step of retrieving the configuration data and the step of calculating the downstream price are executed as a whole in response to the request for the downstream price.

[0056] Optionally, the step of retrieving the configuration data and the step of calculating the downstream price are executed in a layer-by-layer process, in response to separate requests from the separate entities.

[0057] According to another example, a system is provided for calculating a downstream price by applying two or more layers of markup to an upstream price, the two or more layers of markup being configured by separate entities in a supply chain, the system comprising: a central database configured to store configuration data for the two or more layers of markup; and at least one processor configured to, in response to a request for the downstream price: retrieve the configuration data for the two or more layers of markup from the central database; and calculate the downstream price based on the upstream price and the retrieved configuration data for the two or more layers of markup, wherein the at least one processor is configured to execute a calculation algorithm for the two or more layers of markup.

[0058] According to another example, a computer program is provided comprising instructions which, when the program is executed by at least one processor, cause the at least one processor to carry out the method of any of the above-described examples.

[0059] According to another example, a computer-readable medium is provided comprising instructions which, when executed by at least one processor, cause the at least one processor to carry out the method of any of the above-described examples.

[0060] FIG. 1 is a block diagram showing an example of a supply chain for providing a currency according to an embodiment of the present disclosure. In the supply chain, an exchange platform offers its customers a price that includes a markup on top of a platform benchmark price, i.e., the exchange rate at which the exchange platform obtains liquidity from liquid providers, to generate profit for the exchange platform. An entity located at a lower layer of the supply chain is an internal business unit of the exchange platform. Internal and external merchants located at an even lower layer of the supply chain are not directly connected to the exchange platform, but indirectly through various internal business units of the exchange platform. These business units apply additional markups while providing personalized services based on the merchants' individual needs. Examples of such business units may be business units for online money transfer, corporate currency exchange, etc. Examples of internal and external merchants directly served by the business units may include online e-commerce or e-transaction platforms. These merchants apply further markups when providing quotes to users, i.e., specific customers of each merchant.

[0061] In this supply chain, the platform benchmark price may be considered as an upstream price, while the price offered by a specific merchant to a specific user may be considered as a downstream price. It is noted that “upstream” and “downstream” are relative positions, and do not have to be end positions in a supply chain. In other words, it is equally possible to consider, e.g., the price offered by a specific business unit to a specific merchant as a downstream price, when the platform benchmark price is considered as an upstream price, despite that an even further downstream price is present in the supply chain.

[0062] In the instance where the platform benchmark price is considered as an upstream price, and the price offered by a specific merchant to a specific user is considered as a downstream price, the downstream price can be calculated by applying three layers of markup to the upstream price. The three layers of markup are configured by the exchange platform, the business unit associated with the specific merchant, and the specific merchant itself, respectively.

[0063] FIG. 2 is a flow chart showing an example of a method according to an embodiment of the present disclosure. The method is for calculating a downstream price by applying two or more layers of markup to an upstream price, the two or more layers of markup being configured by separate entities in a supply chain.

[0064] The method may include a first step 201 of storing, in a central database, configuration data for two or more layers of markup. The central database may be a database managed by one of the entities in the supply chain, or it may be a database managed by a third party which is not one of the entities in the supply chain. For the sake of data security and integrity, the accessibility of the database may be restricted to the manager of the central database only. Optionally, the manager of the central database collects the configuration data for the two or more layers of markup from each entity in the supply chain and then write the configuration data in the database. Optionally, dedicated software is developed for the collection of the configuration data, and each entity in the supply chain can use the software to transmit the configuration data to the manager of the central database. Alternatively, an interface may be established to allow all or selective entities in the supply chain to write, via a network, the configuration data directly to the central database. This approach may facilitate timely and efficient update of the configuration data and save operational costs. Preferably, the addition and change of the configuration data are performed in a maker-checker process. That is, each addition or change can only be completed after one person makes the addition or change and another person conducts a review of it.

[0065] Preferably, to enhance security and data integrity, all identifiers included in the configuration data, such as an identifier of the entity configuring the markup and/or an identifier of the entity to which the markup is offered, are digital, masked and/or filtered i.e. no information about the real-world identity behind each digital identifier is included in the configuration data. For example, technical personnel who have access to the central database but are not authorized with the information concerning correspondence between the digital identifiers and their real-world identities, cannot know or leak confidential business information. Even if the central database containing the configuration data or a service log associated with the central database leaks, the real-world identities behind the digital identifiers would not be revealed.

[0066] Preferably, the configuration data stored in the central database are uniformly formatted, and an example format of the configuration data will be discussed in more detail with reference to FIG. 3.

[0067] The method according to the example of FIG. 2 may further include a second step 202 of, in response to a request for downstream price, retrieving, by at least one processor, the configuration data for the two or more layers of markup from the central database. The request for the downstream price may be originated from the entity in the supply chain to which the downstream price is to be offered. However, this entity may not be the party that directly sends the request for the downstream price to the at least one processor; rather, intermediaries may be present. The at least one processor may be part of a computing system of one of the entities in the supply chain, or it may be part of a computing system of a third party which is not one of the entities in the supply chain.

[0068] Optionally, the retrieval of the configuration data for the two or more layers of markup from the central database is executed as an integrated data package. Alternatively, the retrieval of the configuration data for each of the two or more layers of markup from the central database may be executed as separate data packages. Preferably, the received configuration data are first stored in data buffers accessible by the at least one processor, before they are used for further calculation. An example of an internal sequence of the retrieval of the configuration data will be discussed in more detail with reference to FIG. 6. [0069] The method according to the example of FIG. 2 may further include a third step 203 of calculating, by the at least one processor, the downstream price based on upstream price and the retrieved configuration data for the two or more layers of markup, wherein the at least one processor executes a calculation algorithm for the two or more layers of markup. Preferably, the calculation algorithm is uniform for the two or more layers of markup.

[0070] The upstream price may be provided by an entity in the supply chain having knowledge thereof, such as a manufacturer of a product taking the cost of the product as the upstream price, or an exchange platform taking the platform benchmark price as the upstream price. The upstream price may be retrieved from a database accessible by the at least one processor, or may be retrieved by invoking a service to fetch the upstream price, as, e.g., will be discussed with reference to FIG. 5.

[0071] The uniform calculation algorithm for the two or more layers of markup may be guaranteed, e.g., by executing the same subroutine, i.e., the same portion of program code, to perform the calculation for the two or more layers of markup. Specifically, the step of calculating the downstream price may comprise calculating an intermediate price by executing the uniform calculation algorithm with the upstream price and a first layer of markup as input values; and calculating the downstream price or a further intermediate price by executing the uniform calculation algorithm with the intermediate price and a second layer of markup as input values. An example of a mathematical formula for calculating the downstream price will be described with reference to FIG. 7. Preferably, the calculated intermediate price is stored in a data buffer, before it is used for the further calculation of the downstream price or a further intermediate price.

[0072] Optionally, the step of calculating the downstream price is executed by a microservice. Such a microservice can be independently developed, changed and upgraded, thereby facilitating better understanding of the calculation process, reducing probability of error and, if errors are present, allowing efficient error tracking. An example of its implementation will be discussed with reference to FIG. 7.

[0073] FIG. 3 is a diagram showing an example of a database/table design according to an embodiment of the present disclosure. The design of this example can be used, e.g., for storing, in a central database, the configuration data for the two or more layers of markup in the supply chain as described in reference to FIG. 1.

[0074] As shown in FIG. 3 and detailed in Table 1 below, the markup configuration may be defined according to four main dimensions: buying currency, selling currency, configuration layer, and configuration identifier. The four dimensions are not always necessary. For instance, the dimension of selling currency is useful for currency exchange, bur may not be necessary for markup configuration in a supply chain for providing a good and a service, in particular, when cross-border trading is not involved. In such a case, the dimensions of buying currency and selling currency may be replaced by a single identifier of a good type or a service type associated with the markup. [0075] Configuration layer: “type” field (1: Platform-to-business markup, 2: Business- to-merchant markup, 3: Merchant-to-user markup). If more markup layers need to be added, this field can be further expanded. In effect, the dimension of configuration layer represents an identifier of the entity configuring the markup. Specifically, when the type is 1 (Platform- to-business markup), the entity configuring the markup is the exchange platform; when the type is 2 (Business-to-merchant markup), the entity configuring the markup is the business unit; and when the type is 3 (Merchant-to-user markup), the entity configuring the markup is the merchant.

[0076] Configuration identifier comprises:

“tag”: a specific identifier for the present layer;

“parent_id”: for distinguishing configurations with the same “tag” under different upper layer configurations. For example, two “user labels” may be the same under different “merchant numbers”. In such a case, they may be distinguished by corresponding to different merchant layer configuration IDs. In effect, the configuration identifier represents an identifier of the entity to which the markup is offered.

[0077] In the example of FIG. 3 and Table 1, the markup configuration data may include a value of the markup, expressed as a base point. If the base point is positive, it is considered as a positive markup; if the base point is negative, it is considered as a discount. All the business units, merchants and users that can be accepted by the exchange platform may need to save their respective markup configuration, and if no markup is needed, the “point” can be configured as 0. Alternatively, the markup configuration data may include a value of the markup, expressed as a percentage in point (pip).

Table 1 [0078] FIG. 4 is a block diagram showing an example of money movement within a supply chain for providing a currency according to an embodiment of the present disclosure, as, e.g., discussed with reference to FIG. 1.

[0079] As shown in FIG. 4, the user only sees an exchange rate quotation and the corresponding transaction amount. In this example, the exchange rate quotation received by the user corresponds to a downstream price calculated by applying three layers of markup to an upstream price, which, in this case, corresponds to the platform benchmark price, i.e., the exchange rate at which the exchange platform obtains liquidity from the liquid providers. The calculation of the downstream price may be performed using the method described with reference to FIG. 2. In addition, the method may further include calculating, by the at least one processor, profits and/or losses for the respective entities resulted from the three layers of markup, the profits and losses being resulted from positive and negative markups, respectively; and storing, by the at least one processor, in the central database, the calculated profits and/or losses in respective accounts of the respective entities.

[0080] In the example of FIG. 4, the profit or loss, which corresponds to the price difference before and after each layer of markup may be calculated and be recorded in the profit or subsidy account of the respective entity. For example, as the exchange platform, when providing the business unit with a selling price of 100 Hongkong Dollar (HKD) for 90 Chinese Yuan (CNY), applies a positive markup to the platform benchmark price, which is 98 HKD for 90 CNY, a profit of 2 HKD may be calculated and stored in the platform profit account. In contrast, as the merchant, when providing the user with a selling price of 100 HKD for 90 CNY, applies a negative markup, i.e., a discount, to the selling price set by the business unit, which is 105 HKD for 90 CNY, a loss of 5 HKD may be calculated and recorded in the merchant subsidy account. The calculation and storage of the profits and/or losses in respective accounts of the respective entities may facilitate efficient and reliable distribution of profits and/or losses among the participants in the supply chain. Costly development and maintenance of separate calculation systems at various layers of the supply chain can be avoided. The centrally stored records may also allow convenient error tracking. [0081] FIG. 5 is a sequence diagram showing an example of a method according to an embodiment of the present disclosure. This example again relates to a method of calculating a downstream price in a supply chain for providing a currency as described with reference to FIG. 1.

[0082] In this example, when a customer quotation service receives an exchange rate quotation request from a caller, it may complete the following process:

[0083] 1. Request for the real-time platform benchmark price from a platform benchmark service. The calculation of the real-time platform benchmark price by the platform benchmark service may be based on the exchange rate information and liquidity situation in the foreign exchange interbank market. Its implementation is not the main concern of the present disclosure, and will thus not be discussed in detail here.

[0084] 2. Obtain, 501, multi-layer markup configuration data from the central database.

The detailed internal sequence of this process will be described with reference to FIG. 6.

[0085] 3. Complete, 502, multi-layer markup calculation based on the configuration data obtained in process 2. The detailed internal sequence of this process will be described with reference to FIG. 7.

[0086] 4. Encapsulate the results of process 3, which may include the calculated downstream price, intermediate prices, profits and/or losses for the respective entities at respective layers, etc., and write the results into the central database and return part of the results or the entire results to the caller. The storage of the calculated downstream price and/or intermediate prices in the central database may, e.g., facilitate transaction verification and error tracking. [0087] The processes 3 and 4 may be executed as a whole in response to the request for the quotation, as shown in FIG. 5. That is, the retrieval of the multi-layer markup configuration data and the multi-layer markup calculation may be executed as an integrated package. In other words, once the customer quotation service is called, it may complete the retrieval of the multi-layer markup configuration data and the multi-layer markup calculation in an unbroken sequence, and, finally, return the final quotation, i.e., the final downstream price, to the caller.

[0088] Alternatively, the retrieval of the multi-layer markup configuration data and the multi-layer markup calculation can be executed in a layer-by-layer process. For example, a service for retrieval of markup configuration data and markup calculation may be called by entities at each layer independently. Each time being called, such a service may retrieve the markup configuration for the respective layer and execute the markup calculation for that layer only. In the example of the supply chain for providing a currency as discussed above, the layer-by-layer calling of the retrieval and calculation may be controlled or coordinated by a business unit, for example.

[0089] FIG. 6 is a sequence diagram showing an example of a detailed internal sequence of the process “Obtain Markup Configuration” 501 in Fig. 5. Some details contained in this example are based on the database design as described with reference to FIG. 3 and Table 1.

[0090] As shown in FIG. 6, the process of “Obtain Markup Configuration” 501 may include the following sequence of sub-processes: a. Request for the markup configuration at the layer of business unit (type=l) based on the buying currency (input parameter), selling currency (input parameter), and business type (input parameter); b. Request for the markup configuration at the layer of merchant (type=2) based on buying currency (input parameter), selling currency (input parameter), merchant number (input parameter), and business layer configuration ID (configld corresponding to the result of a); c. Request for the markup configuration at the layer of user (type=3) based on the buying currency (input parameter), selling currency (input parameter), user label (input parameter), and merchant layer configuration ID (configld corresponding to the result of b). [0091] FIG. 7 is a sequence diagram showing an example of a detailed internal sequence of the process “Calculate Customer Quotation” 502 in Fig. 5. Some details contained in this example are based on the database design as described with reference to FIG. 3 and Table 1.

[0092] As shown in FIG. 7, the process of “Calculate Customer Quotation” 502 may include the following sequence of sub-processes: a. Calculate the price at the business unit layer (busiRate) based on the platform benchmark price and the markup configuration at the business unit layer (busiConfig); b. Calculate the price at the merchant layer (merchantRate) based on the price at the business unit layer (busiRate) and the markup configuration at the merchant layer (merchantConfig) ; c. Calculate the price at the user layer (userRate), i.e., the final price, based on the price at the merchant layer (merchantRate) and the markup configuration at the user layer (userConfig).

[0093] The Markup calculation formula (taking the merchant layer as an example, applying, mutatis mutandis, to the business unit layer and the user layer) may be: merchantRate = busiRate * (1 +merchantConfig.point/merchantConfig.base) [0094] A system is also provided for calculating a downstream price by applying two or more layers of markup to an upstream price, the two or more layers of markup being configured by separate entities in a supply chain. The system may comprise: a central database configured to store configuration data for the two or more layers of markup; and at least one processor configured to, in response to a request for the downstream price: retrieve the configuration data for the two or more layers of markup from the central database; and calculate the downstream price based on the upstream price and the retrieved configuration data for the two or more layers of markup, wherein the at least one processor is configured to execute a calculation algorithm for the two or more layers of markup.

[0095] The system may be further configured to carry out each of the above-discussed examples of methods according to various embodiments of the present disclosure.

[0096] A computer program is also provided comprising instructions which, when the program is executed by at least one processor, cause the at least one processor to carry out each of the above-discussed examples of methods according to various embodiments of the present disclosure.

[0097] A computer-readable medium is also provided comprising instructions which, when executed by at least one processor, cause the at least one processor to carry out each of the above-discussed examples of methods according to various embodiments of the present disclosure.

[0098] Some of the subject matter and operations described in this specification can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Some of the subject matter described in this specification can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions, encoded on a computer storage medium for execution by, or to control the operation of, data-processing apparatus. A computer storage medium can be, or can be included in, a computer-readable storage device, a computer- readable storage substrate, a random or serial access memory array or device, or a combination of one or more of them. Moreover, while a computer storage medium is not a propagated signal, a computer storage medium can be a source or destination of computer program instructions encoded in an artificially generated propagated signal. The computer storage medium can also be, or be included in, one or more separate physical components or media (e.g., multiple CDs, disks, or other storage devices).

[0099] Some of the operations described in this specification can be implemented as operations performed by a data processing apparatus on data stored on one or more computer-readable storage devices or received from other sources.

[00100] A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment. A computer program may, but need not, correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.

[00101] Some of the processes and logic flows described in this specification can be performed by one or more programmable processors executing one or more computer programs to perform actions by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).

[00102] While this specification contains many details, these should not be understood as limitations on the scope of what may be claimed, but rather as descriptions of features specific to particular examples. Certain features that are described in this specification or shown in the drawings in the context of separate embodiments can also be combined. Conversely, various features that are described or shown in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable sub-combination.

[00103] Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single product or packaged into multiple products.

[00104] A number of embodiments have been described. Nevertheless, it will be understood that various modifications can be made. Accordingly, other embodiments are within the scope of the following claims.

Claims

CLAIMS What is claimed is:

1. A computer-implemented method for calculating a downstream price by applying two or more layers of markup to an upstream price, the two or more layers of markup being configured by separate entities in a supply chain, the method comprising: storing, in a central database, configuration data for the two or more layers of markup; in response to a request for the downstream price: retrieving, by at least one processor, the configuration data for the two or more layers of markup from the central database; and calculating, by the at least one processor, the downstream price based on the upstream price and the retrieved configuration data for the two or more layers of markup, wherein the at least one processor executes a calculation algorithm for the two or more layers of markup.

2. The method according to claim 1, wherein the upstream and downstream prices are prices of a good, a service or a currency, and the supply chain is for providing the good, the service or the currency.

3. The method according to claim 1, wherein the calculation algorithm is uniform for the two or more layers of markup.

4. The method according to claim 1, wherein the step of calculating the downstream price comprises: calculating an intermediate price by executing the calculation algorithm with the upstream price and a first layer of markup as input values; and calculating the downstream price or a further intermediate price by executing the calculation algorithm with the intermediate price and a second layer of markup as input values.

5. The method according to claim 1, wherein the step of calculating the downstream price is executed by a microservice.

6. The method according to claim 1, wherein the configuration data for the two or more layers of markup comprises, for each layer, a value of the markup, and an identifier of the entity configuring the markup.

7. The method according to claim 6, wherein the value of the markup is uniformly expressed as a base point or as a percentage in point.

8. The method according to claim 6, wherein the configuration data for the two or more layers of markup further comprises, for each layer, an identifier of the entity to which the markup is offered, and/or an identifier of a good type, service type or currency type associated with the markup.

9. The method according to claim 7, wherein the configuration data for the two or more layers of markup further comprises, for each layer, an identifier of a buying currency type and an identifier of a selling currency type associated with the markup.

10. The method according to claim 1, further comprising: storing, by the at least one processor, in the central database, the calculated downstream price and/or intermediate calculation results including an intermediate price calculated by applying a first layer of markup to the upstream price.

11. The method according to claim 1, further comprising: calculating, by the at least one processor, profits and/or losses for the respective entities resulted from the two or more layers of markup, the profits and losses being resulted from positive and negative markups, respectively; and storing, by the at least one processor, in the central database, the calculated profits and/or losses in respective accounts of the respective entities.

12. The method according to claim 1, wherein the step of retrieving the configuration data and the step of calculating the downstream price are executed as a whole in response to the request for the downstream price.

13. The method according to claim 1, wherein the step of retrieving the configuration data and the step of calculating the downstream price are executed in a layer-by-layer process, in response to separate requests from the separate entities.

14. A system for calculating a downstream price by applying two or more layers of markup to an upstream price, the two or more layers of markup being configured by separate entities in a supply chain, the system comprising: a central database configured to store configuration data for the two or more layers of markup; and at least one processor configured to, in response to a request for the downstream price: retrieve the configuration data for the two or more layers of markup from the central database; and calculate the downstream price based on the upstream price and the retrieved configuration data for the two or more layers of markup, wherein the at least one processor is configured to execute a calculation algorithm for the two or more layers of markup.

15. A computer program comprising instructions which, when the program is executed by at least one processor, cause the at least one processor to carry out the method of any one of claims 1 to 13.

16. A computer-readable medium comprising instructions which, when executed by at least one processor, cause the at least one processor to carry out the method of any one of claims 1 to 13.