US Banks that integrate well with Apple Wallet

Hi all,

I love Apple Wallet app, but my BofA debit card does not show the same analytics as Apple Card shows - balance and activity.

I heard that in UK some banks are well integrated will Wallet via Open Banking.

Is there a bank in US that is fully integrated with Wallet?

Thanks!

reddit.com
u/VitalikPie — 19 hours ago
▲ 13 r/GnuCash

Article: Sharing GnuCash Book Among People or Devices

NOTE: It's not AI-slop. Just documenting what I learned from speaking many people over the last couple years. Proof. Also removed all the links to my app since it applies to any app.

---

Hi! It's been two years of development my own GnuCash companion app I needed to carry a GnuCash book in my pocket.

Since then, I have come to know many people and their setups. And boy, are they different! In this article, I cover common mistakes and pitfalls of accessing a shared GnuCash book using multiple computers and companion apps on Android and iOS.

The basics

First, let's set the stage and expectations.

Unlike cloud-based solutions, GnuCash is a single-user system. Practically, it means that only a single user can access your accounting book at a time.

Also you own your data. It's a blessing and a curse. On one side, your data is visible only to you, on the other side, you carry the responsibility of handling data corruption, conflicts, and simultaneous access.

GnuCash does its best to help you avoid problems. It has locking mechanisms to prevent multiple users in one book. However it's not a bulletproof solution and you still carry a responsibility of backing up your books.

GnuCash can store data in multiple ways.

  • XML - in a text format (it's compressed, though, so not readable out of the box)
  • SQLite3 - a database in a file
  • Hosted database - a database on a computer network or even on the Internet

Who are "the users"

The users can be real people needing access to a shared GnuCash book. Or it can be you accessing your file from multiple devices. So from now on let's not care how many users access the book, but rather how many devices access it.

An important thing here is that GnuCash is inherently a desktop software. However, there are enthusiasts (including yours truly) who develop companion software to access the book from mobile platforms. So the "device" could be a laptop with GnuCash installed or a mobile app.

But before we discuss the mobile apps, let's only consider GnuCash running on multiple devices.

Expectations

If you are a new GnuCash user coming from a cloud-based solution, you are likely used to software that does a lot of things seamlessly.

However, GnuCash perks come at the cost of:

  • Different instances of GnuCash have different data, and you are responsible for merging them semi-automatically
  • Devices take turns accessing the software.
  • Supporting your devices to run the same version of GnuCash.

Ratings

Each solution has its rating on different dimensions.

Dimension What it measures
Safety How safe can I feel about my data getting corrupted?
Automation How much automatic tooling is available vs. how much manual labor it will require to support.
Multi-user How well does this solution work with multiple users.
Real-time How soon do I see data entered in other devices?
Privacy & security How much information do other companies see and how much it's prone for security breaches.

The paranoid way - safest yet most painful

Safety ⭐️⭐️⭐️⭐️⭐️
Automation ⭐️
Multi-user ⭐️⭐️⭐️⭐️⭐️
Real-time ⭐️
Privacy & security ⭐️⭐️⭐️⭐️⭐️

Workflow

  1. Make a copy of your book on each device.
  2. Work on your books however you want (in parallel, offline, however you want)
  3. When ready, merge the books.
  4. Distribute the "master" book among devices.

How to merge books

Good thing - you don't have to manually merge books, transaction-by-transaction. GnuCash gives you a specific format to export and import data while taking care of duplicates.

  1. Choose one book as "master". For other books export transactions using File -> Export -> Export Transactions as CSV…
  2. Open your "master" book.
  3. For every CSV file you have, go to File -> Import -> Import Transactions from CSV … Do not forget to select "GnuCash Export Format" – this turns on a native GnuCash mechanism to work with splits.
  4. Work out any conflicts should they pop up on the last import screen.

The Great File in the Cloud - just a file in a Dropbox

Safety ⭐️
Automation ⭐️⭐️⭐️⭐️⭐️
Multi-user ⭐️
Real-time ⭐️⭐️⭐️⭐️⭐️
Privacy & security depends

It's 2026, Dropbox is 17 years old. A good age to give it a small job to do before graduation. Of course you can choose your tool of preference - iCloud, Google Drive, Syncthing.

One liability that comes with a file in the Cloud is a potential file conflict. There is absolutely no magic behind any Cloud - each device has its own copy of the GnuCash file. If accessed simultaneously, you will have two copies. To add insult to injury, some cloud providers make things obscure and you may not see the issue when it occurred but rather see it so late in the game that it will mean a manual reconciliation of transactions. And last but not least, technical glitches (Cloud process crash, GnuCash crash) happen, and it is totally possible to end up with a corrupted book. Glitches are not unique to this synchronization way, but amplified by a human factor and the frequency of synchronizations.

Workflow

  1. Put your file in a Cloud - Dropbox, iCloud, Google Drive, etc.
  2. Instruct users to never ever access the file simultaneously. If you are the only user, stop being sloppy and forgetting to close GnuCash before closing the lid of your laptop.
  3. Always wait for the cloud provider to synchronize files. If Cloud allows forcing a sync, always use it before opening a GnuCash book.
  4. Be proactive about backups. Do not expect GnuCash mechanisms to save you - you are using an extra piece of software that GnuCash does not know about.

Privacy & security

There is no rating because your privacy and security depend on your choices. Choose a provider that gives away your information without any questions, and you effectively have no privacy. Choose an offline tool like rsync or Syncthing - and you can disconnect from the Internet. As usual, the more privacy and security you want, the more friction you have.

Look ma I'm a DBA! Hosting data in the database

Safety ⭐️⭐️⭐️
Automation ⭐️⭐️⭐️⭐️⭐️
Multi-user ⭐️
Real-time ⭐️⭐️⭐️⭐️⭐️
Privacy & security depends

If you are handy enough and can host a Postgres/MySQL database. This is likely the best option for you.

Instead of storing the accounting book in a file, you can store it in the database. As usual, there are a few tradeoffs - you have to install additional software (Postgres or MySQL), set up the server, connections, and manage security and privacy yourself.

The workflow is pretty much like the previous, with a small exception. The internal GnuCash lock mechanism works much better. Still, GnuCash maintainers are explicitly stating that the lock mechanism is a weak protection:

>

Also, privacy and security is your job. Open your database to the world with a default password - and just wait for someone to delete all the tables. Or air-seal it in a local network without Internet access - and enjoy peace.

Companion apps

There is no official GnuCash app for Android or iOS.

However, there are decent alternatives that you can use as your companion app. You can find more here

All of the apps support only two ways:

  • CSV sync (thus manual merge)
  • Automatic sync via SQLite3 or XML file

It's virtually our first two solutions. So you can confidently use the first two workflows when using the companion app. However, you shall read the disclaimer from GnuCash carefully:

>

While the workflow stays the same, there is one more risk to consider - data corruption by the companion app itself.

The reason here is simple: GnuCash does not provide any official library to work with data files. So every implementation that works with the file directly may not know something and unintentionally corrupt the GnuCash book.

But since there is already a Cloud at play and you are likely backing up your data often (don't you?), you should be good enough to restore from any potential disaster.

reddit.com
u/VitalikPie — 8 days ago

Horse arse set the standard for railways. Spanish traders set it for GnuCash database design

TLDR: Spanish traders in the 1600s did not want to count their thumbs, which influenced GnuCash's database design choices in 1997. Much like a horse's arse set the standard for railways. How seemingly odd design turns out to be a genius solution that serves people pretty well.

It's one of those nights. A cup of hot coffee is on the table. I'm implementing a commodities support in HandsOnMoney which looks absolutely trivial on the surface, but is quite deep in reality. After all, what can be simpler than currency - there are dollars and cents. What can be simpler than storing a number and calculating totals?

Wait for it. There are multiple layers in this…

Layer one. Cultural.

There is not always 100 cents in a dollar. Well, there is. But other currencies may have no "cents" or have a thousand "cents". Those "cents" are generally called "minor units".

Here are a few concrete examples:

  1. Japanese Yen has no minor units (due to post-WWII inflation)
  2. The Kuwaiti Dinar has a thousand minor units (this allows the country to use smaller increments of value and maintain precise pricing for trade)
  3. And Bitcoin has 100 million Satoshis!

But wait for it. There are even historical currency- real de a ocho that could be divided into 8 pieces! So 1/8th of a coin was the smallest indivisible unit!

Which brings us to the next layer - how in the world do we store it?

Layer two. Software.

Computers are not good with fractions. There are abstractions: float and doubletypes. But they are approximations rather than real fractional numbers. The late 90s and early 2000s brought us decimal, which is a much better type; however, it was likely not available when GnuCash was released.

There is a lot written about it. Usually, developers use a double numeric type to record and store the floating-point numbers. But this solution for recording floating-point numbers does not play well with money.

For example, it is possible that.

1.03 - 0.42 = 0.6100000000000001

Which seems like a trivial rounding error. But over a large number of transactions, the rounding error will accumulate, and you'll eventually see a weird account balance.

In addition, money has a fixed precision and specific rounding rules. So software engineers stepped on this landmine so many times that they developed a common pattern - Money. Which, in a nutshell, is just storing minor units in whole numbers since computers are pretty good with them. So instead of recording $5.23, the money is stored as 523 cents.

Problem solved? As you'd expect - no.

Layer three. Historical.

It's not about money. Well, it is. But it is not only about money. It's also about commodities. In a nutshell, money is a commodity. People trade various commodities - currencies, stocks, and funds.

This generalization needs us to go back in the past. And…

Party like it's 1998

It's 1998. The year of the first release of GnuCash (xacc at that time). Dotcom money is pouring from the firehose, party everywhere…

But the most important thing - NYSE quotes are not decimal. They are fractional!

GnuCash was released before the decimalization of US exchanges was completed in 2001.

Why? Get back into the time machine and …

… trade like it's the 16th century

When the NYSE launched over 200 years ago, it adopted the Spanish trading system from the 1600s, based on fractions because traders counted gold doubloons on their fingers, skipping their thumbs. That's why the smallest stock increment was 1/8 of a dollar. Not a technical decision. A thumb decision. (source - Investopedia)

Okay, enough of counting fingers in the 16th century. Let's get back to 2026.

Layer four. Data Engineering.

In 2026, everything is traded in decimals. We are counting fingers and thumbs.

Is GnuCash's design decision to store fractions an artifact from the past?

It already caused a bug

>

Mostly yes. GnuCash is full of little quirks from the past (it still supports Italian Lira, which was replaced with Euro in 1999!).

But this seemingly outdated design decision to store fractions works extremely well in a modern world.

Consider this example: if I bought 1 Bitcoin in 2011 for 90 cents. In my GnuCash book, I recorded

Account Debit Credit
2011 Checking Account 9/10 cents
Bitcoins 1 Bitcoin

Now in 2026. I can sell a fraction of my holdings and price it in Bitcoin's minor unit - Satoshi.

I can easily flip the Bitcoin precision in the commodities editor from 1 to 100,000,000, and GnuCash will still calculate the balance without any issues.

For example, here I'm selling 3 Satoshis in 2026:

Account Debit Credit
2026 Checking Account 1$
Bitcoins 3 / 100,000,000 Bitcoins

It's simple, and that's why it's genius!

However. None of the modern systems work this way. Why?

Layer five. Scalability.

Keeping every amount as a fraction is an extremely flexible solution. However, it is slow.

Adding or subtracting? You need to find a least common denominator.

You need to reduce the results back, or you are risking blowing up past type boundaries.

The complexity and performance at scale are much worse. And considering the fact that everything is traded in decimal fractions now, it's much easier computationally to do: 1150 cents + 1075 cents rather than 11 1/2 dollars + 10 3/4 dollars.

u/VitalikPie — 28 days ago