superzamp

Question is a bit broad, but out of all the concepts under the financial engineering umbrella you're bound to explore the concept of ledgering eventually.

I've written a bit about it on my own co's product blog in an attempt to demystify some core concepts [1], [2], [3].

Still on ledgering and expanding into less mathematical and more applied concepts, I can also recommend a book called "The Accounting Game: basic accounting fresh from the lemonade stand" [4].

[1]: https://www.formance.com/blog/engineering/how-not-to-build-a... [2]: https://www.formance.com/blog/engineering/debits-and-credits... [3]: https://www.formance.com/blog/engineering/ledgering-all-the-... [4]: https://books.google.com/books/about/The_Accounting_Game.htm...

Isn't the screen size difference basically enough between these two? I can't see why the 16" would need more performance, some ppl just want / can carry large computers with them while some other prefer to have something as small as possible.

I think it's even realistic to say that dotfiles are vulnerable to being used as a fingerprint mechanism by nefarious packages. One could easily create an inventory of github profiles <> dotfiles; then read local dotfiles when their package gets installed on a developer laptop.

Well, France just took a stance and officially qualified this as terrorism [1] for the first time.

[1] https://www.diplomatie.gouv.fr/fr/dossiers-pays/israel-terri...

If you want to treat yourself with an accounting game night, there's this one built by @patio11: https://keshikomisimulator.com/

PS: it's not highly visible in the link but this post is 6 months old [1]. Wondering where they are now, given that they seemed to have less than that in runway.

[1] https://community.preciousplastic.com/questions/questions-on...

I would imagine that getting the user out of the in-app purchase payment screen and attempt to redirect them at the website for payment, have them figure out how to enter credit card details etc would result in a drastically decreased conversion rate though.

Attempts at doing this are effectively already existing, the IEX [1] exchange being an example, albeit on a less ambitious scale than your idea:

> It's a simple technology: 38 miles of coiled cable that incoming orders and messages must traverse before arriving at the exchange’s matching engine. This physical distance results in a 350-microsecond delay, giving the exchange time to take in market data from other venues—which is not delayed—and update prices before executing trades

Oh I definitely agree with that. I’m just wondering here if having something mechanical, predictable, deterministic (instead of whatever the hell that is that we have right now) wouldn’t be an interesting way to align incentives.

If that's the goal, one might wonder why are tariffs implemented in such a static way. Why not having your own tariffs importing from XYZ be updated on a monthly basis based on what XYZ imported from you last month.

| Formance | formance.com | OSS Financial Infrastructure | NYC, Paris |

Currently hiring for Product Engineers [1], with a background in fintech/payments to work on our ledgering, reconciliation, and accounting systems. We have a highly modular product architecture, so this is a very good opportunity for a technical person who want to drive and own a scope of our platform moving forward.

We don't really care about your tech-stack background in the sense that adapting to ours is the easy part if you have enough experience already. Everything is open-sourced at github.com/formancehq if you want to check it out.

Location: Paris, FR or Europe (Remote) Compensation: Above €75K with equity, exact offer based on experience.

---

[1] https://posthog.com/blog/what-is-a-product-engineer

Send us a note at jobs@formance.com (mention HackerNews in the subject)

The graph seems to be alright, there are indeed red and (some) green pixels, looks like an issue with your extension unfortunately.

> Anastasios Angelopoulos, with beard, and Wei-Lin Chiang

What is going on here, are we suppose to specify people's position in a photo according to facial features now?!

(Disclaimer: I’m the author, nice to see your take here and pleasantly surprised to see my post here as well!)

You can surely use accounts with fine grained attributes (e.g. to describe the soon to be received but not yet available money or customer 1234, naming it users:1234:pending). You can even add more data to this account on a metadata level (e.g. finer grained accounting classification).

The problem with an account-only approach is that a monetary value represented in it is only temporarily represented here, and if there’s a specific set of attribute relative to that value, you’ll be somewhat forced to overly complicate your structure of accounts to persist theses values throughout the ledger.

Banks are not fintech and hence face different issues so let’s take an example anchored in that context. Imagine you’re holding $100 for user 1234, spread across two FBO accounts at two different banks. You might be interested in persisting the nature and location of these funds throughout the ledger. So instead of having an account structure such as users:1234:main:jpmc, users:1234:main:fargo and so on, you could simplify your ledger structure by having a single users:1234:main holding something like:

    [USD/2 100 (bank: jpmc)]
    [USD/2 100 (bank: fargo)]

So that no matter the complexity of your ledger transactions, you’ll always be able to « reveal » the identity of these funds which would otherwise be lost in a ledgering model optimized for classical accounting.

But that’s just an example, the idea is to explore the concept of semi-fungibility and how it can improve some of the challenges fintech face (in their journey of being not bank).

> Does recording it twice

Double entry is (confusingly) not about recording it twice, it's about using a transaction model where the state of N accounts has to be changed in compensating directions within a transaction for it to be valid, N being >= 2.

So depending on how your transaction schema is defined, a double-entry transaction can be written without ever even repeating the amount, e.g.

    {"debit": "cash:main", "credit": "giftcards:1234", "amount": 100}

Making it effectively impossible to represent invalid state change. Things get trickier when N > 2 as classical double-entry tend to _not_ directly relate tuples of accounts directly to one-another and instead relying on a aggregated balancing of the changes to the N accounts at the transaction level, though YMMV between different ledgering systems.

Precisely. Designing a transactional system can be solved. Designed a transactional system that properly entangles the bits with the assets they represent is the hard part.

Coincidentally written something about this yesterday [1], but the gist of my take summed up is that the nature of accounting oriented data models doesn’t help when dealing with multiple FBO accounts.

The main problem is that accounting defaults to full fungibility of monetary amounts represented in a ledger, which has the effect of losing track of the precise mapping between assets and liabilities, so you end up in a position where you simply cannot tell precisely to a bank _who_ are the actual customers they owe money to.

[1] https://www.formance.com/blog/engineering/warehousing-promis...

There's already "parasitic computation" so we could probably go for "parasitic data storage"

You could take a look at how the Formance ledger [1] is built for some inspiration and take it from there.

A few pointers I’d have would be:

* Decide what this ledger will be in charge of (keeping balances? Answering fast and in volume to a balance-bound transaction commit? Financial reporting with complex aggregations?)

* Choose a transaction data model that optimizes for what’s most important in your use-case (tracking value movement, tracking change to the financial position of your business, etc). This would define wether what operations on accounts can happen along with how accounts can be relate to one another in a transaction.

* Pick a proper monetary values representation format, likely a variant of Decimal or Integer + Currency code. If you don’t use big numbers with infinite lengths, define what happens at boundaries when numbers overflow.

Have fun!

[1] https://github.com/formancehq/ledger

Not as of today!

Thanks for the heads up! While the Numscript backend itself uses big.Int, we're still using normal javascript numbers in the playground for now so that's where it's coming from. But we should definitely switch to BigInt in the playground code though and that would solve the issue.

Yeah that's a good question, you'll want to leverage the `overdraft` functionality for that, enabling the account end balance to go below zero.

So you could do something like:

    send [USD/2 10000] (
      source = @my_bank:loans_made allowing unbounded overdraft
      destination = @my_bank:1234
    )

With the post-transaction balance of @my_bank:loans_made becoming [USD/2 -10000]. So that's for creating money out of nothing.

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-...

For this particular case, I would say that tax-brackets sort of logic can be expressed in the destination block with ordered destinations.

For example, you could have something like this:

    send [USD/2 *] (
      source = @users:1234
      destination = {
        // first $1000 are taxed at 10%
        max [USD/2 100000] to {
          10% to @taxes
          remaining kept
        }
        // Anything above that is, taxed at 20%
        remaining to {
          20% to @taxes
          remaining kept
        }
      }
    )

(You can test it on the playground, you'll just want to feed the "users:1234" account with an initial balance in the input section)

Well that's definitely a good puzzle. I've tried to model it for a bit, but it indeed looks like we'd need to add something to the language to make it possible at all! Thanks for bringing this up.

That's a very good question. So the DSL here operates an agnostic source/dest transaction model, which is akin to the credit/debit model sans the semantic baggage. The goal of this model is indeed to be "tracking transactions" in the abstract sense, having the benefit of not forcing accounting decisions too early on when there is (still yet) none.

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.

Yes exactly! There's actually two implementations, one tightly knit to our ledger product located at [1] and the new, standalone one (used by the playground) at [2]. In any case, in both implementations, the DSL is indeed MIT.

[1] https://github.com/formancehq/stack/tree/main/components/led...

[2] https://github.com/formancehq/numscript

It's indeed relative to cents in a sense, the idea is to force you to declare the precision of the monetary amount you're expressing.

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...

If you see micro-services as (a domain boundary + an atomic infrastructural unit), maybe the latter is debatable but the application domain do need 2800 boundaries anyway? Especially for such a large company, especially for a company operating in financial services.

The next line of thinking to this is that nobody is forcing Apple to sell their devices in the EU.

The people of EU have decided through their votes that they will delegate consumer devices compliance rules to bodies orchestrating manoeuvres like this one. This comes with the benefit of knowing that someone's forcing companies that want to sell you widgets to go through various hoops that will supposedly make the widgets better for you.

If consumers want to outsource less protections from widget vendors and let Apple do its thing, they can vote for it.

(Not arguing either way, just fixing flawed logic here).

We have a pretty minimal setup at formancehq/ledger[1] that uses pg as a storage backend, and comes with a programmability layer to model complex transactions (e.g. sourcing $100 from three accounts in cascade).

[1] https://github.com/formancehq/ledger