Enter the Lateral Income Transfer Filter (LITF). A dry name, perhaps, but an accurate one. This is something I put together, but it's both simple enough and obvious enough that I expect others to eventually reach something similar as their own conclusion to this paying-for-a-UBI puzzle.
A LITF fixes (and funds) a UBI by pairing it with an income tax of identical size. The two are tightly coupled; between them they share a single free parameter, alpha (range 0 to 1 inclusive), and together they constitute a closed system [1] with no side-inputs or -outputs. Here's [2] how it works:
Let P be a group of individuals of size n, the participants, in the LITF. Each participant has an income.
Insert the LITF across the participants' income streams. This makes the LITF a filter with n inputs and n outputs. The filter should be inserted after all of a participant's various incomes are accounted for. Exemptions (adding income downstream to where the filter has been applied) are not impacted by the filter; the math allows them, but they do undermine the purpose and efficacy of the LITF.
The LITF applies an income tax of alpha to each stream.
The LITF applies a UBI of alpha * average_income to each stream.
[1]I generally describe the LITF using signal processing as my paradigm. I know that most people aren't that familiar with signal processing, so I will try to describe concepts as they arise.
[2]
I am using a slightly simplified model for the purpose of explanation. This simplified model assumes that incomes are all known and fixed at the time that the LITF is applied. In reality, incomes arrive in irregularly spaced and variably sized chunks. As a result, in order to apply the LITF in real time, incomes are being treated as discretized signals [2-1]. The filter still applies as expected: when a chunk of income (say a paycheque) arrives, some amount is taxed, and some basic income is added. The differences are two-fold:
Incomes are per-unit-time based. Your basic income will still add up to the same amount, but if you receive infrequent incomes, it'll be dispensed in larger chunks than if you receive frequent incomes.
The 'average' income, on which basic income is based, is estimated.
[2-1]'Discretized' here means that the signal comes in distinguishable pieces, rather than as a continuous flow. The difference between using buckets and using a hose to transport water.
It is this second aspect, of estimated basic income, which is more interesting. The estimator incurs a group delay between its value and the theoretical actual value. This represents a small difference in time between when a impulse in the populations' income signal hits the population, and when it shows up in the estimator. An example of such an 'impulse' could be e.g. a tax break, a recession, etc. Recursive filters (like a Butterworth filter ⬈) can be used to keep this group delay small.
That's it! Two steps, and nothing more complicated than computing an average is involved.
I'll now explore some filter characteristics of the LITF, which will give you an idea of both its effect on participants' incomes and the guarantees [3] that it makes.
The filter has a gain of 1. Gain is the factor by which the magnitude of the signal changes, or the ratio of the output to the input. This means that the sum of money flowing into the filter equals the sum of money flowing out of the filter, or that no money is created or destroyed by the LITF. This shows that an LITF requires no additional money over its administrative costs to run.
The filter's profile is continuous. There are no steps, cliffs, or other discontinuities that participants may use to try to conduct arbitrage.
The filter preserves monotonicity in participants' incomes. If a participant's pre-filtered income rises, their post-filter income is guaranteed to also rise. Symmetrically, if their pre-filter income falls, their post-filter income will also fall.
The filter preserves income ordering. If participant a has a higher pre-filter income than participant b, then a's post-filter income is guaranteed to be higher than b's post-filter income. This means that if you were to order the participants by their incomes, the filter would not disturb this order.
The filter narrows the spread between its inputs. The difference between a's income and b's income is guaranteed to decrease across the filter. This means that the filter decreases income inequality.
The filter dampens a participant's income signal. The rises don't raise so much, but so too the falls don't cut so deep. It generally makes all participant's income streams more stable and less volatile.
The filter introduces no group delay. This means that when a participant's pre-filter income changes, their post-filter income will change in the immediately succeeding step without introducing lag. Note that this result only holds for our simplified LITF model; averaging is not instantaneous, and there will be a group delay in any real-world LITF implementation.
[3]Some of the guarantees above are violated at the corner cases where alpha is 0 or 1.
Alpha is the LITF's free parameter [4]. It has a range from 0 to 1 (inclusive), and can be treated as though it were a knob that can be used to adjust the opacity or strength of a LITF. Here are our corner/boundary cases:
0. The LITF is completely transparent. Participants' pre-filter incomes are exactly equal to their post-filter incomes (specifically, their income is taxed 0% and then they are paid a UBI of $0). When alpha is set to this value, it is as though the filter doesn't even exist. This setting is good for turning the LITF off, and for instantiating and destroying it.
1. The LITF is completely opaque. Participants' post-filter incomes are all exactly equal, irrespective of their pre-filter incomes (specifically, their income is taxed 100%, and they are paid a UBI of whatever the group average income is). This setting is good for guaranteeing equity between participants.
[4]There is no 'correct' value for alpha, hence it being a free parameter, however my general suggestion is that when a LITF is implemented, it should start at 0, and be slowly adjusted up to somewhere in the neighborhood of 0.4.
Alpha determines the amount by which participants' incomes are shifted towards the group's average. Higher values result in larger shifts that make the filter more opaque, and lower values vice versa.
Any given LITF is a function of the participants P that compose it. A single participant may however belong to more than one LITF. When there is an overlap, the LITFs are said to intersect. Intersections come in a variety of shapes:
The total intersection, in which two separate LITFs have identical sets of participants. In this case, the two can be combined into a single LITF. If the two LITFs have alpha_a and alpha_b as their respective parameters, the combined single LITF has a parameter of alpha_intersection = alpha_a + alpha_b - alpha_a * alpha_b.
The covered intersection, in which one set of participants is a strict subset of the other. Because LITFs averaging effects (where participants' incomes are shifted towards their collective average) are multiplicative, participants who belong to both LITFs will see a stronger effect than those belonging to just one.
A LITF ends up producing some interesting incentives for participation →, as well as some interesting bonuses →.