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].
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.
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.
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.
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.
(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:
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).
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.
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.
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.
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...