* Payments involving vouchers and a user's prepaid balance * Complex funds destination scenario where the customer gets cash back * Configurable user credit balance spending transactions
The main idea is to take the pain out of describing of a system dealing with money movements should behave in traditional languages such as JS/TS/Go/Ruby etc, landing an expressive way to model these movements of value.
It is voluntarily broad in applicability—our customers use it today for use-cases ranging from marketplaces funds orchestration to home-grown loan management systems.
Once those transactions are modeled, they are to be picked up and committed to a system-of-record, ledgering system or executed on a set of payments and banking APIs.
It was initially a DSL we bundled into our Core Ledger product at Formance (YCS21) but we're giving it more autonomy now and started to make it standalone, with the idea that anyone could eventually bolt Numscript on top of their ledgering system. We're also exploring to make it natively compatible with other backends.
As part of this un-bundling, we've just shipping a playground which lets you fiddle with it without installing anything at https://playground.numscript.org/ (it works best on desktop).
Happy to chime in on any questions!
Amounts ending in 1 cent and 2 cents are rounded down to the nearest 10 cents;
Amounts ending in 3 cents and 4 cents are rounded up to the nearest 5 cents;
Amounts ending in 6 cents and 7 cents are rounded down to the nearest 5 cents;
Amounts ending in 8 cents and 9 cents are rounded up to the nearest 10 cents;
Amounts ending in 0 cent and 5 cents remain unchanged.
send [CADCASH/2 12] ( source = @user1 destination = @user2 )
"postings": [{"source": "user1",
"destination": "user2",
"amount": 10,
"asset": "CADCASH/2"}]
[1] https://www.canada.ca/en/revenue-agency/programs/about-canad...
You can see various interpretation of what "USD" means in the wild, as some APIs will happily parse USD 100 as $1.00 while some others might parse USD 100 as $100.00.
So we recommend this explicit [ASSET/SCALE AMOUNT] notation, where SCALE describes the negative power of ten to multiply the AMOUNT with to obtain the decimal value in the given ASSET.
It makes subsequent interaction with external systems much easier. You can read a bit more about it here [1].
[1] https://docs.formance.com/stack/unambiguous-monetary-notatio...
ref child post about stocks trading for 0.0001. Yes, those are real trades and (probably) fully legal etc, but I'm not sure the Fed recognizes currency amounts less than 1 US cent ($0.01), so the accounting rules and tax rules might not match expectations based on generalized floating point math.
Our system was a payment system for childcare management software, interfacing with banks and the government directly.
Not sure why you'd need to make a note in the internal representation, vs. leave adapters to handle conversions.
https://beancount.github.io/docs/the_double_entry_counting_m...
E: the problem being “tracking transactions”. Yes?
For example, if you create a transaction moving money from "@stripe:main" to "@acct:123" and "@acct:234", you're merely representing the fact that you want this money to be moved. Wether the movement is clearing off a liability or generating revenue is another concern that you (in our model) want to take care of in a separate layer, that will also likely involve some intense intentionality and iterations from your accounting team.
In a sense, it's as close to accounting than it is to warehousing money, moving unitary boxes of it from one location to another.
These two models have the same amount of information per entry, so they can actually be converted from one to another, enabling you to also represent some accounting-ish transactions with this DSL, e.g. with a send [USD/2 100] from @ar:invoices:1234 to @sales.
I don’t have a need for this personally but I’ll definitely be bouncing this around in my head for a while, both technically (JS ALL the things!) and methodologically. Accounting is pretty trivial when you don’t have any income to track!
The equivalent of DR @my_bank:loans_made 10000, CR @my_bank:1234 10000
So you could do something like:
send [USD/2 10000] (
source = @my_bank:loans_made allowing unbounded overdraft
destination = @my_bank:1234
)
There's a little bit more to it if you want to create accounting-perfect entries, but a simple way to map src/dest to cr/dr entries is to say that every credit becomes a destination, and every debit becomes a source.
You can then consider debit normal accounts as having their debit balance being equivalent to the sum of entries where the account is source, their credit balance as the sum of entries where the account is destination—and do the opposite for credit normal accounts.
We've written a bit more about it here [1].
[1] https://docs.formance.com/ledger/advanced/accounting/credit-...
How would you handle a three legged agency bank transaction as you get in a BACS file (source, Nostro, destination)?
How would you handle a three legged agency bank transaction as you get in a BACS file (source, Nostro, destination).
https://www.microsoft.com/en-us/research/publication/composi...
It is quite powerful and you might want to look at it for possible features to use.
[1] https://github.com/formancehq/stack/tree/main/components/led...
go install github.com/formancehq/numscript@latest
go: downloading github.com/formancehq/numscript v0.0.8
go: downloading github.com/antlr4-go/antlr/v4 v4.13.1
go: downloading github.com/sourcegraph/jsonrpc2 v0.2.0
go: downloading golang.org/x/exp v0.0.0-20240707233637-46b078467d37
Numscript cli
Usage:
numscript [command]
Available Commands:
check Check a numscript file
help Help about any command
Flags:
-h, --help help for numscript
-v, --version version for numscript
Use "numscript [command] --help" for more information about a command.But this seems to have more programming language like features if I understand correctly. What else is different?
Now let's see a "ContentScript" for posting content to ledgers :D
send [Image "tacos.jpg", Text "taco 2sday!"] (
source = @bschmidt1
destination = @us-west-relay
)