It’s also a huge vector for actual phishing, especially because google ads doesn’t use puny code, so it’s easy to buy ads for sites that differ by just a diacritic
That's how my stepdad got hacked. He didn't understand bookmarks or urls or homepages, so he just opened his browser at google.com, searched for the name of his bank, clicked the first ad, and went to log in. Usually that worked for him, but once, he got a scam site, and he was on the phone with a call center in India giving them remote desktop access before a single alarm bell went off in his head.
Granted, it's partly my fault for letting a loved one be that computer un-savvy, but that kind of ad should have been detected and blocked before it was ever served.
Agreed. There are so many failures on Google’s end to let this happen. One of which was allowing the advertiser to display a legitimate URL in the ad while redirecting to an illegitimate one. I really hope this isn’t the case any more.
I sent my father in law an article the other day, and he wound up clicking a scam ad that got his computer hacked. He showed it to me, it wasn't the most obviously scammy ad I've seen- plenty of people who didn't grow up with the internet might have fallen for it!
But anyway, on my laptop, the article was just clean text and a byline with some well-formatted images.
Failing to install ublock on your parents computer is a form of abuse! :-)
- For customers on our partner bank Evolve, this was bumped from 1mm to 3mm as of this morning. You get this automatically if you have accepted the T&Cs for the sweep program already; if you haven't you can do so at: https://mercury.com/settings/vault
- For customers on our partner bank Choice, you're still at 1mm FDIC insurance. We are working on getting you an Evolve savings account (or getting increased coverage from Choice) by tomorrow morning, or you can keep excess funds in Treasury (see below)
# treasury
- We also have a product called Mercury Treasury. This allows you to invest in mutual funds, the safest of which is a Vanguard Treasury Money Market fund (VUSXX), which invests primarily in short-term U.S. Treasury bills https://investor.vanguard.com/investment-products/mutual-fun...
- They're not part of any fractional reserve system like with banks; every share of a mutual fund you hold is in your name and Apex can't lend against it (unless you give them permission which would be weird)
- You can automatically sweep any funds between our treasury product and your savings account. Liquidity is about 3 to 4 days.
- All treasury funds are visible on your Mercury dashboard, so you don't have to manually manage fund movements or keep track of your total balance across websites
- You also earn interest on these
AMA if you'd like, though caveat I'm jumping between a lot of Slack messages right now (edit: probably bowing eat to eat lunch)
Each bank your money is in increases FDIC coverage by 250K.
Who is the owner of record on these Mercury accounts at "other banks"?
Can I withdraw *my* money from these "other banks" without Mercury involvement or approval? If not, then *Mercury* may have increased FDIC coverage but the Mercury depositor does not.
You as the customer are the owner of record on the funds. The accounts are held by our partner banks at these other banks, as your agent and custodian (something like "Evolve Bank and Trust for benefit of Acme Corp).
The FDIC insurance applies to the business holding the funds; it is definitely not insuring Mercury itself.
You do need to use Mercury to withdraw the funds; we still run all the authorization and compliance rules around this, and there isn't a facility for you to go into eg United Texas Bank and ask for your money. That said, if Mercury were to go bankrupt tomorrow, your funds are held by our partner banks who have full KYC/KYB info on you would be able to access all your funds.
You might consider providing a "living will" document that keeps your clients up-to-date on where the $$$ are and how they access them. If I'm using something like this I would want to be sure I can make payroll the day after you vanish.
(Not a potential customer or cash management expert, prioritize accordingly.)
My best guess, not until OK'd by a bankruptcy judge. You may have a strong claim on the funds but so does Mercury --- hence the fact stated above that you can't withdraw without their approval. On the other hand, they may be able to withdraw without your approval. A bankruptcy judge is the only one who could override their claim and release these funds to you.
Remember, SVB was an FDIC bank. The reason depositors are able to withdraw money today is because of the quick actions of the FDIC.
My guess, this is a trust/FBO co-mingled type account of some sort.
Only Mercury knows the exact structural details but based solely on their statement above, they have significant control and claims that you can't easily override yourself.
I wouldn't count on this all being resolved quickly in the event of a bankruptcy.
This is the question that needs to be answered before everyone starts throwing their money at these sweep accounts.
SVB offered sweep accounts. Guess how that worked out for folks with money in those accounts? They lost access just like everyone else. If you had a sweep account and you needed to make payroll on Friday, you were not protected.
> We also have a product called Mercury Treasury. This allows you to invest in mutual funds, the safest of which is a Vanguard Treasury Money Market fund (VUSXX)
Mercury charges 60bps for their Treasury product. Why the hefty fee for buying MMFs? VUSXX expense ratio is 9bps for comparison.
Hey Max, I think your offering is amazing but it might be built for the world of yesterday: Since starting this weekend apparently all deposits are 100% insured, why would I go to Mercury to take advantage of sweeps or a money market fund, when my bank offers me slightly higher rates for uninsured-but-insured-in-practice deposits?
1. As others have said in the comments, I wouldn't assume all funds are 100% insured. It is trending that way but I think if you are a CFO managing 10s of millions, its responsible to consider other assets.
2. Our interest rates on Treasury are pretty competitive, up to 4.67% for the slightly-less-conservative fund MULSX (various conditions apply, depends on how much you hold in treasury, etc; see https://mercury.com/treasury for details).
We are OK not having the absolute highest interest rate offering. Our position is:
* The Mercury product is much better than what most banks offer, across features like searching transactions, WebAuthn logins, virtual cards, etc (You can try the whole website at https://demo.mercury.com/)
* Mercury is much better optimized for startups (eg compliance that understands startup needs, doesn't ask your CEO to go into a branch to send wires)
You can always get a higher interest rate by eg buying treasuries yourself. Our position is for most founders, investing in these mutual funds is a safe, no-brainer options that optimizes for safety while keeping the convenience of a single dashboard.
I get this line of thinking, but I also think there's a counterargument that we're all on notice now that banks can go under. As commenters in other threads have noted, people are rebalancing their personal and business accounts right now. Companies like Roku probably won't have $400M at one institution anymore (without outside insurance). That means that if this happens again, many of the people who would have been screwed without a backstop this time around will be in the clear next time. There won't be as much pressure applied by high-level executives and lobbyists, so, as the saying goes, "past performance is not a guarantee of future results".
How is this safer than the alternative? There's no world in which the FDIC lets a bank the size of SVB default on it's deposits, so there are basically 2 scenarios here:
1) You get bailed out no matter what your insurance rate
2) Defaults are at such a high rate that the FDIC doesn't have the money to bail everyone out, the economy tanks, and all businesses that rely on risky VC investment fail anyway
It's like betting $100 on something that won't happen until you're dead. Sure, you might be correct, but there's no real benefit to it.
Queue can also allow batching. It might be that you need to consume or pack or ship N items at a time, otherwise you're losing money. Trying to aim for minimal latency would literally hurt your business.
This article obviously has a very specific kind of workload/service/target in mind that they fail to define and they overgeneralize. This is bad advice in many situations that they failed to imagine.
We had a credit reporting agency (big US one, suffered a large data breach a few years ago) try and insist that we require password expiration for our employees.
After pointing to the NIST standards (and two other references) saying that that reduced security and saying "we're not prepared to reduce our security" they backed off.
> After pointing to the NIST standards (and two other references) saying that that reduced security and saying "we're not prepared to reduce our security"...
Tip for those in settings with compliance reviews and cybersecurity insurance: get your PCI DSS, SOX, and other auditors, and cybersecurity insurance underwriter on board with these standards as well, with written statements. Then if Big Customer Co. pushes back after you say, "we're not prepared to reduce our security", ask them in a friendly way to hold an N-way meeting between their auditors and insurance underwriter, and your auditors and insurance underwriter.
This gets them to switch off their demand. Every. Time. If they don't back off on their own, their auditors and/or insurance underwriter makes them back off. I've yet to have such a Big Customer Co. push it to the point of asking more than one of their own auditors, though. Usually it is someone not in auditing and insurance underwriting blithely following outdated policies written in the Stone Age that still need updating, and most are grateful for the updated clarification.
You have to get out ahead of the business risk though for this to work: you need to properly socialize the delay this puts on the deal "while auditors and insurers sort out the risk". This is where soft skills shine.
This approach will also take care of the response user patrakov gave ("NIST is an American institute, and we are a Japanese company, we have our own standards that differ, and must follow them"), once it gets to the insurance underwriters talking it over on how to divvy up the risk and amend their policies if necessary.
The only PCI DSS requirement I couldn’t quickly align to NIST and others has been the 90 day expiration. My go-to has been to convince the insurance underwriters first of the primacy of SANS, NIST, Microsoft and so on. Then put them in a locked cage match with the PCI DSS auditors and accept the result when they walk out. PCI DSS auditors can’t accept liability shifting onto them, and cybersecurity insurance underwriters are getting more savvy on current standards and can often twist auditor arms enough to carve out exceptions and still obtain the audit certification.
It’s still messy at this time, but if it is important enough to you, then sometimes it can be obtained. Most of my clients aren’t that doctrinaire over the expiration part though and are still comfortable making everyone change every 90 days, and with some enterprises they don’t care because they have FIDO2/U2F or similar authN infrastructures and corresponding authZ improvements on their roadmaps within the next 3-5 years anyways that do away with most passwords in their environments.
> Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.
Sure! I used NIST[0] (which has already been posted here), along with Microsoft[1] and the UK National Cyber Security Centre[2] (we're in the UK as well as the US).
For context, I remember the contract first came back, and we redlined it saying we're not gonna do password expiration and explained why. It then came back with another draft and they said "no, this is our policy, you definitely need to do password expiration" so I threw these references together and expanded my explanation. It was a bunch of business/lawyer types, so I threw microsoft in there as I assume they're better known to non-technical people and the other two references are obviously more salient to technical people.
As a side-note I think this was _after_ they had their very well publicized security breach, and I would have hoped that they had taken a look at their security and updated their policies but I guess that wasn't the case. I don't know whether they ended up removing it from their contracts going forward or just made an exception for our one. The cynical part of me says the latter (it's a big firm, and we're not a particularly big one) but I can hope.
I also recently read an audit for another third party we were evaluating to work with. I raised it as a non-blocking concern saying they're not following modern password standards, and I think if everyone does that these companies will start to update their policies but for now it's fairly common at least in my industry.
[EDIT] I went looking for what I actually said to them, and it was "as per UK/US government and Microsoft password guidelines, we will not agree to this, and would prefer if you didn't do it as well.". So I guess I was a bit exasperated with them at the time :)
This is likely the best way to deal with the inertia exerted by antiquated requirements: Most (keyword being 'most') businesses tend to follow the rules laid out by authorities, so an appeal to authority works in this regard.
Agreed, huge thanks to NIST for the sane password policy recommendations. While it is still an uphill fight to bring sanity into this mess, being able to quote NIST and say we're following their recommendation has been very helpful.
The appendix, “Strength of Memorized Secrets” is informative rather than a guideline, but I would recommend quoting it too in such discussions:
> composition rules, which require the user to choose passwords constructed using a mix of character types, such as at least one digit, uppercase letter, and symbol. However, analyses of breached password databases reveal that the benefit of such rules is not nearly as significant as initially thought… although the impact on usability and memorability is severe
Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically).
There’s other great stuff in there as well like that you should allow users to “paste” passwords and potential passwords should be checked against a list of known bad ones.
Expiring passwords are the bane of my existence. My current job does that. It was originally a requirement by Microsoft and they've been recommending against it, but it catches up slowly.
Expiring passwords are the bane of my existence when the period is short. I can live with changing a password once a year, but every three months is only encouraging me to pick weak passwords.
Why can I accept it? I constantly see colleagues sharing passwords and constantly have to say "please don't" when they try to share their password with me. While forcing people to change their passwords doesn't eliminate the underlying problem, it does limit the scope of the damage.
My old man's work used to make them change their passwords once a month.
For the next 10 years, his password was a particular insulting phrase directed at the IT guys, followed by a number that would increment each time he had to change it. Got into the hundreds before he left the company.
I had a coworker that would type in something random as his new password, then immediately fail to login three times in a row so his account would get locked. To fix this the sysadmin would reset the password, and allow you to choose a new password... and on the no-repeated-passwords policy did not apply to the magical reset dialog. So he would then reset it to his old password.
I was doing the same at one point, albeit it only lasted 5 years before I changed employers. Didnt even had to rotate the numbers, I could always come up with new and colorful insults for the nameless IT group. Which ironically I remember perfectly.
Changing the password opens it to compromise when it's being changed. Capture of that account is possible and easy at that point.
It also interferes with password managers and secure keys.
Opens a phishing vector. Generally I could enumerate how bad it is and run out of ink here. (And it's a screen.)
My former company required not to use one of the last 10 passwords. So every 3 months, employees did the 11-password dance, setting the password back to the original one.
I know passphrases are better. But, the problem is there's much more to type every time you want to unlock your computer. And thus also many more chances to make a typo.
Of course there's TouchID and Windows hello but they don't work if your laptop is closed in a dock. Or in my case a Mac mini at home.
This is why I still stick to the truly random sorry password, I have no issues remembering arbitrary strings for some reason :)
Typing a passphrase is so much easier. You already have muscle memory for typing English (or whatever your first language) words. I can type probably type a 60 character passphrase consisting of real words at least as quickly as than I can type a 15 character password with special characters, if not faster.
For you maybe, not for me. I'm pretty good with arbitary strings. And I'd only use specials that don't require shift :) It's really much faster and I have RSI so I don't want to type too much.
Luckily my work still allows 10-char with specials or passphrases of 16 and longer without. And don't forget passphrases only benefit in very specific situations such as hash brute forcing. Online attacks already block after a handful of attempts.
Also, the incessant screen locking really annoys me, every time I step away for a coffee my PC is locked again, and this is also at home where my environment is completely secure and I'm the only one living there. I actually work in security but sometimes there is just no reason and it becomes just a barrier.
In the past I used an app to jiggle the mouse every once in a while but that doesn't work anymore. I now made a digispark that does the same in hardware. :) I only use it at home though and it auto-locks my desktop when I leave the house (all my personal ones do too)
If they'd just allow us to use our yubikey + pin it would be so much easier and more secure...
I type my arbitrary 12 character password for my laptop as quickly as I’d type two 6 letter common words, due to muscle memory, as I don’t have to change it every few months.
In all serious, my point is roughly that typing Sp3c1al_(h4racTer_p@ssw0rd$ is like O(n) whereas typing passphrases is like O(log n). Once you hit a certain length, pass phrases start pulling ahead in ease-of-use.
We're already constantly maintaining muscle memory just by typing normal words every day. With muscle memory for special character passwords, you have to start over from scratch every time you have to change one.
In other words, imagine I flipped over a flashcard with a new passphrase on it consisting of lowercase English words, and asked you to type it. Now imagine I flip over a flashcard with a new, special character password. How many more times do you think you'd have to reference the flashcard with the special character password while typing it out and developing the muscle memory over the flashcard with the passphrase?
Windows allows you to use a PIN for regular device logon - so you have a longer, more secure password for general use of the account, but an eg 8 digit numeric PIN _only_ for that device.
> Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.
Across the pond, there is also the NCSC password guidance. It's better than linking to some obscure paragraph in a standards document; it's written in plain English, aimed at the layman, and explains exactly why the old doctrines are bad:
I work for an insuretech startup and have been through a number of compliance gauntlets with large enterprise insurance companies. Appealing to NIST recommendations for why we don't auto-expire passwords every x days and don't require anything more complicated than at least 10 characters has worked on every occasion.
The topic of "what should we do about our password policies" sometimes comes up with our customers as well. Pointing to NIST and if pressed giving my opinions on good passwords and the use of 2FA (which is largely paraphrasing NIST recommendations anyway) made every customer happy so far :)
Whats the requirement for an LLC? I tried signing up for Mercury after getting the email from Brex and seeing it mentioned here but was rejected today. This is a Florida LLC that is around a year old. After linking my Brex account and providing my information I received an email saying that you guys cannot move forward but did not provide a reason why.
Could you clarify the minimum requirements for being a Mercury customer?
That's great to know. While I have you here, could you just clear one thing up for me?
On your home page, you say you are not a bank. From what I can tell, you seem to be a wrapper around a bank(s) (Choice Financial Group and Evolve Bank & Trust®). Does that mean signing up with you gives me an account with those banks, or do I still have to sign up with those banks independently in order to use your service?
I'm sorry if this seems like a stupid question, but it isn't apparent to me from a quick scan of your website.
EDIT: Last question... if your customers aren't required to establish a direct relationship with your underlying banks, how do you handle KYC? Would I need to fly to the US to get this started, or would a zoom session plus all the relevant ID's be enough?
> Does that mean signing up with you gives me an account with those banks, or do I still have to sign up with those banks independently in order to use your service?
Neither. The funds are held by those banks, but you won’t ever deal with them directly nor have any login to them
> Would I need to fly to the US to get this started, or would a zoom session plus all the relevant ID's be enough?
You just sign up online and provide documents. No zoom sessions.
If you have the relevant documents signing up should take ~15 minutes
> We're doing all we can, and working with other financial service providers to make this transition as smooth as possible.
The biggest thing for us would be if you could support Plaid's Identity product by returning names and emails when someone links a Brex account with Plaid.
When someone links an account using Plaid, having this data available means we can compare that to the names/emails we have on file and have verified. If it's a match, this makes it _dramatically_ less likely someone is trying to commit ACH fraud against a Brex customer.
This makes it safer for us to offer higher ACH pull limits to that customer. Even for customers who never switch away from Brex, this would significantly increase protection from ACH fraud.
I just wanted to say that I absolutely understand why you prefer users to use Plaid's identity product (the startup I work at does this as well), but I HATE that it's becoming the standard way to link checking accounts. Both from a data sharing perspective, and from a training users to enter login information into random forms perspective.
There has got to be a better way for us to accomplish this.
Plaid is a menace. My checking account was synced on Venmo just fine using the small transfer method for years until plaid was introduced. I redid the old school verification 3 times before giving up and linking via Chase. I changed the password afterwards but of course that unlinked me again. Can’t wait until some regulatory agency comes after them.
It really annoys me how some service/startup gets build around the large "infrastructure" (in a broader sense) deficiencies in the US. Because of the size of the US market and the amount of VC funding they then become big and move into markets that have had perfectly functioning solutions (like the EU in this case). Because they are so flush with cash (and much conversation/advertising online is very US centric) they then become dominant even in markets which had a perfectly functioning system that never needed they solution.
Uber is an example of this (taxis had issues in Europe/Australia as well, but by far not as problematic)
> There has got to be a better way for us to accomplish this.
One path forward is Oauth, which several major institutions use on Plaid (Capital One, Wells, Chase are ones I know of).
This definitely solves “entering login information into random forms”.
I’m pretty sure I have seen these institutions offer you some control over what data you share when you link, but it was minimal control, and didn’t work well. Ideally that would be more fleshed out.
You’d still be sharing balance and transaction data with Plaid though, that part isn’t solved by Oauth. I think to solve that you need to have a European style standard banking API that makes direct bank-to-bank data sharing tenable?
There should be a law for this. The EU as an open banking API law, that requires banks to make this data available electronically over an API.
The US needs an open banking law. This should not be an optional feature for banks to offer. It should be an absolute requirement.
I think it's insane to enter your credentials into Plaid. Almost every banking agreement I've ever seen disclaims liability if your account is breached because you shared your password. So, if you share your password with Plaid, and Plaid is breached, and someone uses your banking credentials to drain your account, I think a bank could wash their hands of it and walk away in that situation.
I'm sure the Plaid engineers are great, and that their data is stored securely (and maybe they don't store the password at all in there systems). But I'm not willing to bet my entire bank account on them being perfect.
Plaid is almost 10 years old and I think there are probably several verbatim comments on HN since the introduction of Plaid. Unfortunately I don't think we will ever see a such a law; the landscape has changed from 10 years ago and:
1. Plaid has been pretty much been blessed by the largest player in the space (the , now blocked, acquisition from Visa).
2. The banks are glad to outsource development of banking apis to one single customer. Even CapitalOne who seemed horrified at the integration built an Oauth endpoint.
3. The queue of banking regulations is a mile long and is deeply politically controversial among those who vote.
4. Our geriatrics in congress will never see this as an
important issue.
Oh, yes, I would absolutely never use Plaid, or any service that requires it in the meantime.
But, there are many services that should exist, that could be safely used, if such an API mandate existed.
I actually think it’s a matter of time. Eventually the current state of affairs will lead to a crisis. Someone operating like Plaid (a centralized nexus of banking passwords) will be breached, funds will be drained, and banks will shrug.
At that point, the API law becomes much more likely. Banking regulations have a way of moving very slowly until a crisis erupts.
Another path is, once most of the bigger banks develop their own APIs, they will probably push for the regulation as a path to making it harder for smaller banks to compete.
> if you share your password with Plaid, and Plaid is breached, and someone uses your banking credentials to drain your account, I think a bank could wash their hands of it and walk away in that situation.
is "Plaid is breached" necessary? Or is it enough for bank to be aware that you used Plaid?
I don’t know, I’m not a lawyer, just a concerned bank customer that read my TOS.
My guess would be that your bank account being compromised would need to flow in some way from you sharing your password. But, it might be a matter of “who has the resources to make a claim in court”, which could be a challenge for most people if they just lost their bank account (hell, it would be hard for most people even with access to their savings)
From what I remember from reading my bank contract: they claim that any password sharing and blatantly insecure behavior waive bank responsibility.
It may not be enforceable, but in my case any use of Plaid or Plaid-like tool would allow bank to claim that they are no longer responsible for any fraud.
(for reference - I am from Poland, never encountered any nonscam asking me for my bank account, though banks have different variety of problems)
[I work at Plaid] Not to get into too much of this, but the Consumer Financial Protection Bureau has issued guidance that banks are still required to comply with the consumer protection measures provided by Reg E (and thus cannot fully disclaim liability) even when a fraudulent transfer is the result of password sharing. More info at https://www.consumerfinance.gov/compliance/compliance-resour...
Though this is still obviously not a replacement for open banking and would I still love open banking laws in the US (and hopefully better implemented / constructed than the open banking laws in Europe!)
I don't see anything that would extend the coverage to a service that is providing a read-only view into the account, or anything that mentions password sharing. I _think_ I could see what you're describing in maybe the description of the transitive nature of Regulation E to cover "non-bank payment providers", but I don't see anything that would protect me if I shared my bank password with Mint via Plaid?
I'd love to know more, and as a lay person I'm having a hard time working my way through all the language of Regulation E.
Sure. The most relevant section would be the "Error Resolution: Unauthorized EFTs" FAQ section in the link in my previous post, especially FAQs 4-8.
(Also, just to clarify how Plaid works, Plaid does not share account credentials with Plaid's customers, so you wouldn't be sharing your password with Mint via Plaid. Instead, Plaid provides token-based access to data via an API.)
After looking at those answers and reviewing the relevant parts of Regulation E that it cites, I do feel like the regulation pretty-comprehensively disallows banks to impose liability on the consumer for sharing their password. Answer 8 especially that notes that no waiver of Regulation E is allowed makes me feel more comfortable.
I'd still support an open-banking API law, but your citations here have really turned down the urgency for me on that issue.
(And, yep I'm familiar that Plaid does not share the password beyond itself and the relevant bank it's authenticating with)
Iirc, with our current partner bank Evolve + technology provider Synapse, ACHs and wires have “Synapse” as the sender name on a certain field, instead of your business name.
This is (as far as I understand) wrong. Fortunately
it usually doesn’t break anything, but Circle is more strict about this saying the business name.
We have a new partner bank we just launched where we have full control of the ACH stack, where we’ve resolved this. Also trying to fix the issue with the existing partner.
Caveat that I didn’t check this answer with anyone, since it’s early.
We use to be with Synapse and Evolve too - have thankfully moved on ;) We went through the same pain with Synapse that it's their name and not the customer's name on the wire. I thought at Mercury's scale you could get them to change this by now.
Mercury rejected our LLC when we applied there yesterday so not sure where to go now (and no idea why we were rejected). Is there any reason not to go with Bluevine?
Does this sound correct to you / if so can you remedy it with Rhode Island? (edit: our onboarding team says you specifically want a Certificate of Good Standing from the state)
That said, this should have been communicated as a clear rejection reason—we'll work on that.
Yeah we are waiting on accountant to finish taxes (which are on extension) for 2021 so we can submit and get a statement of good standing with RI so we can renew our registration. Mail forwarding failed to forward our annual statement document for 2021 so we won't be in good standing with RI until that happens. I got in touch with accountant today to see if they can escelate but they are still a few weeks out.
Every.io sounds interesting. Except I have never heard of the company, there are misspellings on the webiste and the address is a mail drop in San Francisco. And nobody else ever heard of the company with zero links or information anywhere online. So they pay 4% APY but its a company nobody ever heard of.
