I'm not sure where I first heard of rubber duck debugging, but in my experience there is rarely a physical rubber duck at all. It's more of a "can I rubber duck you on something for a minute?" "Yea, sure!" "<starts explaining> ... ah I've figured it out cheers".

If you put it in a sun-synchronous orbit then it will always be in sunlight. Such an orbit would be in LEO.

Except when it's on the dark side of the earth - for half of every ~90 minute orbit.

A "sun-synchronous orbit" is typically a polar orbit that precesses so that it's sunside pass is always "over" the same local time (say, noon(ish)).

That puts it over the antipodean midnight time once it crosses the pole.

If you're thinking of a different orbit, how does that work?

From the wikipedia article on SSO’s that I linked above:

> the dawn/dusk SSO orbit, where the local mean solar time of passage for equatorial latitudes is around sunrise or sunset, so that the satellite rides the terminator between day and night. Riding the terminator is useful for active radar satellites, as the satellites' solar panels can always see the Sun, without being shadowed by the Earth.

That's a single SSO on the terminator.

There are many SSO's for all the times of the day, most SSO's are not permantly in sunlight.

The comment I replied to implied that any old SSO would have the property of being always in the sunlight, this isn't true.

The particular issue with a terminator SSO is that region will get crowded (sure, space is large) and one collision will seed debris to spoil it for everyone for some time.

> Riding the terminator is useful for active radar satellites ..

All sats need some level of power or another, not all want to ride the terminator, see (for one example)

https://modis.gsfc.nasa.gov/about/

in which different sats in the constellation travel at different times of day (why?).

It’s a dusk-dawn orbit. So if it’s over an equatorial point at dusk, it’s over the antipode at dawn (and in sunlight the whole orbit).

Not all SSO's are dawn dusk, and that's limited "real estate" see: https://news.ycombinator.com/item?id=41478468

Thanks for the feedback! Most people have been using free online templates to create docs (or random unrelated PDFs) but we'll consider adding sample documents next time.

If we fix business banking onboarding there will be no need for this!

At least where I am (in Sweden) that would require scaling back the amount of paperwork banks feel they need to “KYB”. Opening a bank account today requires about the same amount of paperwork as a loan application 20 years ago. You have to submit a business plan with a SWAT analysis. I kid you not.

That's shocking! I guess regulators haven't loosened up in Sweden. Curious how a business plan is relevant for opening a bank? (loans make sense ie feasibility/risk to repay etc.).

We're predominately selling to US neobanks and fintechs, right now focussing on the smaller ones that are less tied into their existing solution.

KYB is vastly more complex than KYC because there are more things that need to be checked, and for each one a large range of acceptable proof documents. There are also many more edge cases e.g. change of business name or structure, foreign beneficial owners etc. that make an end-to-end solution tricky.

There are other players in this space but they tend to be tools to assist human analysts. We want to fully automate the low risk cases so that they never require human intervention.

Not necessarily vastly more complex because KYC has its own challenges (being accessible to end users, it is open to massive fraud rings).

But KYC is such a different problem space that few KYC companies would venture into KYB (and the other way around).

The compliance analysts that we have spoken too feel stretched too thin with a huge backlog of cases. We free them up from having to do menial document verification for low risk companies so they can spend more time on the more interesting high risk work.

That is just the first step -- we both know the next step is replacing them entirely, and you would if you could.

Thanks for playing, this is useful info!

There's a big difference between the nature of fraudulent documents submitted to our customers today, and the ones that one might create knowing that the system is build with LLMs - we've mostly optimised for the former so far.

I'm also glad to see it took a number of attempts - security through obscurity is not something we want to rely on but the real system requires your identity and will offboard you without explanation at the first hint of misbehaviour.

We'll continue to improve our system to be more vigilant and make fewer assumptions.

Without explanation sounds like when platforms auto ban you without giving a reason or send you endless unsolvable captchas.

It is not possible to give the reason for offboarding as it may tip off fraudsters on how they can evade detection next time. This is standard across the industry.

i.e. "Security through obscurity" - which isn't a phrase with a good reputation in these parts...

I note that if you know your way around the dark web, it's relatively straightforward to find a "financial crimes advocacy" website with suggestions on evading KYC and other compliance hurdles; obviously I won't repeat them here (and I know that probably the majority of would-be bank fraudsters probably aren't into checking the darkweb for advice) so I hope there's more to it than just information-control...

It's a great point, but I'm afraid this is what the regulators enforce onto the banks/fintechs, out of our hands!

Try it on the demo, let us know how it goes!

Yes, I would definitely put Arva in that category.

For now, we limit the amount of decisioning that is made by an LLM and make as much of the business logic as we can concrete in code. It's mostly used to extract information from documents, crawl websites and identify specific fraud signals.

So what you're saying is that you could've done this startup a decade ago without LLMs using traditional NLP and ML techniques. Or even just with straight up procedural code, OCR and a rules engine. Especially since as you say everything you're dealing with is highly structured.

I work at a bank and everything you mentioned was solved many, many years ago. So the more interesting question then is why are fintechs still using manual techniques despite having the capability to automate it.

Not quite!

Fintechs often still have humans review docs, websites, perform web due diligence etc. Efficacy has vastly improved at these validation steps with the assistance of LLMs.

Interesting to hear that your previous bank has automated all of low/medium risk already, from what we have seen more traditional banks are far behind fintechs and are more risk averse in using new technologies. Nice to see that's not the case with all traditional banks.

> Efficacy has vastly improved at these validation steps with the assistance of LLMs.

Is that "efficacy" as the (customer-hostile) bank defines it, or is this more holistic interpretation that also factors in false-positives?

i.e. can you assert that things are better now for everyone, including the completely innocent people who often get caught-up in Kafkaesque KYC ("KKYC?") loops?

Yup exactly that! One of the benefits of what we're building is that fintechs/banks can now approve good customers quicker. So the innocent ones benefit greatly from Arva.

> can now approve good customers quicker

Well, that's half of it.

What about people who get disapproved because they were flagged by some automated screening? ...they end-up getting stuck in limbo because they were flagged, so they can't even (for example) close-out and withdraw any other accounts they have with the same institution - and they can't get any help because of the "we-can't-tell-you-how-to-evade-KYC" rules.

Stuff that happens all the time: https://www.nytimes.com/2023/04/08/your-money/bank-account-s...

Decision making is also more accurate, human analysts often deviate from procedure. Also why banks/fintechs often spend so much on QA teams just to observe how the human analysts have performed.

Transaction monitoring is different, that's post account opening.

When people are going through an onboarding flow it is their first account!

Depends on the fintech! 99% don't have 100% automation for all low/medium risk.

Very cool! Congratulations on the launch, and best of luck to you!

Thanks!

We use Gemini as they offer stronger guarantees around not training on your data ve e.g. OpenAI. We are also looking at self-hosting open source models in the future.